MySQL Cluster

MySQL Cluster es una versión de alta disponibilidad, alta redundancia de MySQL adaptada para el entorno de computación distribuida. Usa el motor de almacenamiento NDB Cluster para permitir la ejecución de varios servidores MySQL en un cluster. Este motor de almacenamiento está disponible en las distribuciones binarias de MySQL 5.0 y en los RPMs compatibles con las distribuciones Linux más modernas. (Tenga en cuenta que tanto los RPMs mysql-server como mysql-max deben instalarse para tener la capacidad de MySQL Cluster .)

Lo sistemas operativos en que MySQL Cluster está disponible son Linux, Mac OS X, y Solaris. (Agunos usuarios han reportado éxito al ejecutar MySQL Cluster en FreeBSD, aunque no está soportada oficialmente por MySQL AB.) Estamos trabajando en hacer que Cluster se ejecute en todos los sistemas operativos soportados por MySQL, incluyendo Windows, y actualizaremos esta página en cuanto se soporten nuevas plataformas.

Este capítulo representa el trabajo en progreso, y sus contenidos son objeto de revisión mientras MySQL Cluster evoluciona. Información adicional acerca de MySQL Cluster puede encontrarse en la web de MySQL AB http://www.mysql.com/products/cluster/.

Puede usar dos recursos en línea adicionales proporcionados por MySQL AB:

Lista de correo de MySQL Cluster.
El área de Cluster del MySQL User Forums.

Puede encontrar respuestas a preguntas comunes acerca de Cluster en Sección 16.10, “Preguntas frecuentes sobre MySQL Cluster”. Si es novato en MySQL Cluster, puede encontrar útil el artículo de la Developer Zone How to set up a MySQL Cluster for two servers .

16.1. Panorámica de MySQL Cluster

MySQL Cluster es una tecnología que permite clustering 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 barato, 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. La relación de estos componentes en un cluster se muestra aquí:

Todos estos programas funcionan juntos para formar un MySQL Cluster. Cuando se almacenan los datos en el motor NDB Cluster, las tablas se almacenan en los nodos de datos. Tales tablas son directamente accesibles desde todos los otros servidores MySQL en el cluster. Por lo tanto, en una aplicación de pago que almacene datos en un cluster, si una aplicación actualiza el salario de un empleado, todos los otros servidores MySQL que acceden a estos datos pueden ver el cambio inmediatamente.

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 unas pocas 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.

Al llevar MySQL Cluster al mundo Open Source , MySQL propociona tratamiento de datos clusterizado con alta disponibilidad, alto rendimiento, y escalabilidad disponible para todo el que lo necesite.

16.2. Conceptos básicos de Basic MySQL Cluster

NDB es un motor de almacenamiento en memoria que ofrece alta disponibilidad y caracterísitcas de persistencia de datos.

El motor NDB puede configurarse con un rango de opciones de fallo y balanceo de carga, pero es más sencillo arrancarlo con el motor de almacenamiento a nivel de cluster. El motor de MySQL Cluster NDB contiene un conjunto completo de datos, dependiente sólo de otros datos dentro del propio cluster.

Ahora describiremos cómo inicializar un MySQL Cluster consistente de un motor NDB y algunos servidores MySQL .

La porción de cluster del MySQL Cluster está configurada independientemente de los servidores MySQL . En MySQL Cluster, cada parte del cluster se considera como un nod.

Nota: En muchos contextos, el término "nodo" se usa para indicar una máquina, pero cuando se discute MySQL Cluster significa un proceso. Puede haber cualquier número de nodos en una máquina, para los que se usa el término máquina cluster.

Hay tres tipos de nodos cluster, y en una configuración MySQL Cluster mínima, al menos habrán tres nodos, uno de cada tipo:

El nodo de administración (MGM) : 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 así. 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 comandondb_mgmd.
El 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.
El nodo SQL: 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 típicamente se arranca con el comando mysqld --ndbcluster o símplemente usando mysqld con ndbclusterañadido a my.cnf.

La configuración de un cluster implica configurar cada nodo individual en el cluster y inicializar los enlaces de comunicación individual entre los nodos. MySQL Cluster está diseñado con la intención que los nodos de almacenamiento son homogéneos en términos de procesador, espacio de memoria, y ancho de banda. Además, para proporcionar un punto único de configuración, todos los datos de configuración del cluster entero se guardan en un único fichero de configuración.

El servidor de administración (nodo MGM) administra el fichero de configuración del cluster y el log. Cada nodo en el cluster recibe los datos de configuración del servidor de administración, y necesita una forma de determinar dónde reside el servidor de administración. Cuando ocurren eventos interesantes en los nodos de datos, los nodos transfieren información acerca de estos eventos al servidor de administración, que guarda la información en el log del cluster.

Además, puede haber cualquier número de procesos clientes del cluster o aplicaciones. Hay de dos tipos:

Clientes MySQL estándar: No son diferentes para MySQL Cluster que para cualquier MySQL (no cluster). En otras palabras,MySQL Cluster puede ser accedido para aplicaciones MySQL existentes escritas en PHP, Perl, C, C++, Java, Python, Ruby, y así.
Clientes de administración: Estos clientes conectan al servidor de administración y proporcionan comandos para arrancar y parar nodos, arrancar y parar traceo de mensajes (sólo en versiones de depuración), mostrar versiones y estatus de nodos, arrancar y parar copias de seguridad, y así.

16.3. Cómo configurar varios ordenadores

16.3.1. Hardware, software y redes
16.3.2. Instalación
16.3.3. Configuración
16.3.4. Arranque inicial
16.3.5. Cargar datos de ejemplo y realizar consultas
16.3.6. Apagado y encendido seguros

Esta sección es un “Cómo” (“How-To”) en el que describimos las bases para planear, instalar, configurar, y ejecutar un MySQL Cluster. A diferencia del ejemplo de Sección 16.4, “Configuración de MySQL Cluster”, el resultado de las guías y procedimientos descritos a continuación deben ser utilizables para MySQL Cluster con unos requerimientos mínimos para disponibilidad y salvaguardia de los datos.

En esta sección, cubrimos requerimientos de hardware y software; red; instalación de MySQL Cluster; configuración; arrancar, parar y reiniciar el cluster; cargar una base de datos de ejemplo; y realizar consultas.

Suposiciones básicas

Este How-To hace las siguientes suposiciones:

Estamos preparando un cluster con 4 nodos, cada uno en máquinas separadas, y cada uno con dirección de red fija en una Ethernet como se muestra:

Nodo Dirección IP

Nodo de administración (MGM) 192.168.0.10

Nodo MySQL server (SQL) 192.168.0.20

Nodo de datos (NDBD) "A" 192.168.0.30

Nodo de datos (NDBD) "B" 192.168.0.40

Puede verse mejor en el siguiente diagrama:

Nota: Para mayor simplicidad, usamos sólo direcciones IP numéricas en este How-To. Sin embargo, si la resolución de DNS está disponible en su red, es posible usar nombres de equipos en lugar de direcciones IP al configurar el cluster. Alternativamente, puede usar el fichero /etc/hosts o el equivalente en su sistema operativo para proporcionar significado al hacer la búsqueda de equipos si está disponible.
Cada equipo en nuestro escenario es un PC de sobremesa basado en Intel con una distribución Linux genérica instalada en disco con una configuración estándar, y ejecutando sólo los servicios necesarios. El sistema operativo con un cliente de red TCP/IP estándar es suficiente. Para simplicidad, asumimos que el sistema de ficheros en todas las máquinas está configurado igual. En caso que no fuera así, necesita adaptar estas instrucciones.
Tarjetas 100 Mbps o 1 gigabit Ethernet están instaladas en cada máquina, junto con sus drivers, y las cuatro máquinas están conectadas via un elemento de red Ethernet como un switch. (Todas las máquinas deben usar tarjetas de red con la misma velocidad; esto es, las cuatro máquinas del cluster deben tener tarjetas 100 Mbps o las 4 máquinas deben tener tarjetas 1 Gbps.) MySQL Cluster funcionará en una red 100 Mbps ; sin embargo, gigabit Ethernet proporciona mejor rendimiento.

Tenga en cuenta que MySQL Cluster no está diseñado para una conectividad de red menor a 100 Mbps. Por esta razón (entre otras), intentar ejecutar un MySQL Cluster en una red pública como Internet no funcionará y no está recomendado.
Para nuestros datos de prueba, usaremos la base de datos world disponible para descarga en la web de MySQL AB. Como ocupa poco espacio, suponemos que cada máquina tiene 256 MB RAM, que debe ser suficiente para ejecutar el sistema operativo, proceso NDB del equipo y (para los nodos de datos) almacenar la base de datos.

Aunque nos referimos a Linux en este How-To, las instrucciones y procedimientos que proporcionamos aquí pueden adaptarse tanto a Solaris como a Mac OS X. Suponemos que sabe realizar una instalación mínima y configurar el sistema operativo con capacidad de red, o que puede obtener asistencia cuando lo necesite.

Discutimos los requerimientos hardware ,software, y de red de MySQL Cluster con más detalle en la siguiente sección . (Consulte Sección 16.3.1, “Hardware, software y redes”.)

16.3.1. Hardware, software y redes

Una de las ventajas de MySQL Cluster es que puede ejecutarse en hardware normal sin ningún requerimiento especial a parte de grandes cantidades de RAM, debido al hecho que todos los datos se almacenan en memoria. (Tenga en cuenta que esto puede cambiar y que queremos implementar almacenamiento en disco en versiones futuras.) Naturalmente, CPUs múltiples y más rápidas mejoran el rendimiento. Los requerimientos de memoria para procesos cluster son relativamente pequeños.

Los requerimientos de software para Cluster son modestos. Los sistemas operativos de las máquinas no requieren ningún modulo no usual, servicios, aplicaciones o configuración extraña para soportar MySQL Cluster. Para Mac OS X o Solaris, la instalación estándar es suficiente. Para Linux, una instalación estándar debe ser todo lo necesario. Los requerimientos del software MySQL son simples: todo lo necesario es una versión de producción de MySQL-max 5.0; debe usar la versión -max de MySQL 5.0 para tener soporte de cluster. No es necesario compilar MySQL para usar cluster. En este How-To, asumimos que está usando el -max binario apropiado para Linux. Solaris, o Mac OS X disponible en la página de descargas de MySQL http://dev.mysql.com/downloads.

Para comunicación entre nodos, el cluster soporta red TCP/IP en cualquier topología estándar, y como mínimo se espera una red 100 Mbps Ethernet , más un switch, hub, o router para proporcionar conectividad de red al cluster entero. Recomendamos que MySQL Cluster se ejecute en su subred que no está compartida con máquinas no-cluster por las siguientes razones:

Seguridad: La comunicación entre nodos del cluster no están encriptadas. La única forma de proteger transmisiones dentro de un MySQL Cluster es ejecutar su cluster en una red protegida. Si trata de usar MySQL Cluster para aplicaciones Web , el cluster debe residir detrás de un firewall y no en su DMZ (DMZ) o en otro lugar.
Eficiencia: Inicializar un MySQL Cluster en una red privada o protegida permite que el cluster haga uso exclusivo del ancho de banda entre máquinas del cluster. Usar un switch esparado para su MySQL Cluster no sólo ayuda a protegerse de accesos no autorizados a los datos del clsuter, también asegura que los nodos del cluster están protegidos de interferencias causadas por transmisiones entre otras máquinas en la red. Para mayor confianza puede usar switches duales y tarjetas duales para eliminar la red como punto único de fallo; varios dispositivos soportan fallos para estos enlaces de comunicación.

Es posible usar la Scalable Coherent Interface (SCI) con MySQL Cluster, pero no es un requerimiento. Consulte Sección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más información.

16.3.2. Instalación

Cada máquina MySQL Cluster ejecutando nodos de almacenamiento o SQL deben tener insalados el binario MySQL-max . Para nodos de almacenamiento, no es necesario tener el binario MySQL server instalado, pero tiene que instalar el demonio del servidor MGM y los binarios de clientes (ndb_mgmd yndb_mgm, respectivamente). En esta sección, cubrimos los pasos necesarios para instalar los binarios correctos para cada tipo de nodo del cluster.

MySQL AB proporciona binarios precompilados que soportan cluster y que no tiene que compilar. (Si necesita un binario personalizado, consulte Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”.) Por lo tanto, el primer paso del proceso de instalación para cada máquina del cluster es bajar la versión más reciente de su plataforma desde MySQL downloads area. Asumimos que los guarda en el directorio /var/tmp de cada máquina.

Hay RPMs disponibles para plataformas Linux 32-bit y 64-bit; los binarios -max instalados por los RPMs soportan el motor NDBCluster . Si elige usarlos en lugar de los binarios, tenga en cuenta que debe instalar ambos el paquete -server y el -max en todas las máquinas que tendrán nodos del cluster. (Consulte Sección 2.4, “Instalar MySQL en Linux” para más información acerca de instalar MySQL usando RPMs.) Tras instalar de los RPM, todavía tiene que configurar el cluster como se discute enSección 16.3.3, “Configuración”.

Nota: Tras completar la instalación no arranque los binarios. Le mostraremos como hacerlo siguiendo la configuración de todos los nodos.

Instalación de nodos de almacenamiento y SQL

En cada una de las 3 máquinas designadas para tener los nodos de almacenamiento o SQL, realice los siguientes pasos como root del sistema:

Compruebe los ficheros /etc/passwd y /etc/group ( o use cualquier herramienta proporcionada por el sistema operativo para tratar usuarios y grupos) para ver si hay un grupo mysql y usuario mysql en el sistema, como algunas de las distribuciones de sistema operativo los crean como parte del proceso de instalación. Si no están presentes, cree un nuevo grupo mysql y un usuario mysql para este grupo:
```
  groupadd mysql
  useradd -g mysql mysql
```
Cambie al directorio que contiene el fichero descargado; desempaquételo; cree un symlink al ejecutable mysql-max. Tenga en cuenta que el nombre del fichero y difectorio cambia en función del número de versión de MySQL .
```
  cd /var/tmp
  tar -xzvf -C /usr/local/bin mysql-max-5.0.10-pc-linux-gnu-i686.tar.gz
  ln -s /usr/local/bin/mysql-max-5.0.10-pc-linux-gnu-i686 mysql
```
Cambie al directorio mysql , y ejecute el script proporcionado para crear las bases de datos del sistema:
```
  cd mysql
  scripts/mysql_install_db --user=mysql
```
Configure los permisos necesarios para los directorios de MySQL server y de datos:
```
  chown -R root .
  chown -R mysql data
  chgrp -R mysql .
```
Tenga en cuenta que el directorio de datos en cada máquina con un nodo de datos es/usr/local/mysql/data. Haremos uso de esta información al configurar el nodo de administración . (Consulte Sección 16.3.3, “Configuración”.)
Copie el script de arranque de MySQL en el directorio apropiado, hágalo ejecutable, y configúrelo para arrancar junto al sistema operativo:
```
  cp support-files/mysql.server /etc/rc.d/init.d/
  chmod +x /etc/rc.d/init.d/mysql.server
  chkconfig --add mysql.server
```
Aquí usamos Red Hat chkconfig para crear enlaces a los scripts de arranque; use lo que sea apropiado para su sistema operativo / distribución, tal como update-rc.d en Debian.

Recuerde que los pasos listados anteriormente deben realizarse separadamente en cada máquina en que el nodo de almacenamiento o SQL residen.

Instalación del nodo de administración

Para el nodo MGM (administración), no es necesario instalar el ejecutable mysqld, sólo los binarios para el cliente y servidor MGM, que pueden encontrarse en el archivo -max descargado. De nuevo asumimos que ha guardado este fichero en /var/tmp. Como root del sistema (esto es, tras usar sudo, su root, o su equivalente en su sistema para asumir temporalmente los privilegios de administrador de sistema), realice los siguientes pasos para instalar ndb_mgmd y ndb_mgm en el nodo de administración del cluster:

Mueva el directorio /var/tmp , y extraiga ndb_mgm y ndb_mgmd del archivo a un directorio disponible como /usr/local/bin:
```
  cd /var/tmp
  tar -zxvf mysql-max-5.0.10-pc-linux-gnu-i686.tar.gz /usr/local/bin '*/bin/ndb_mgm*'
```
Vaya al directorio en que ha desempaquetado los ficheros, y hágalos ejecutables:
```
  cd /usr/local/bin
  chmod +x ndb_mgm*
```

En Sección 16.3.3, “Configuración”, crearemos y escribiremos los ficheros de configuración para todos los nodos del cluster de ejemplo.

16.3.3. Configuración

Para nuestro cluster de 4 nodos y 4 equipos, necesitamos escribir 4 ficheros de configuración, 1 por nodo/equipo.

Cada nodo de datos o SQL necesita un fichero my.cnf que proporciona dos informaciones: unconnectstring diciendo al nodo dónde encontrar el nodo MGM , y una línea diciendo al servidor MySQL en este equipo (la máquina del nodo de datos) que se ejecute en modo NDB.

Para más información de connectstrings, consulte Sección 16.4.4.2, “El connectstring de MySQL Cluster”.
El nodo de administración necesita un fichero config.ini que le diga cuántas replicas mantener, cuánta memoria reservar para datos e índices en cada nodo de datos, dónde encontrar los nodos de datos, dónde se guardarán los datos en cada nodo de datos, y dónde encontrar los nodos SQL.

Configuración de los nodos de almacenamiento y SQL

El fichero my.cnf necesitado por los nodos de datos es muy simple. El fichero de configuración debe estar localizado en el directorio /etc y puede editarse (y crearse en caso necesario) usando un editor de texto, por ejemplo:

vi /etc/my.cnf

Para cada nodo de datos y SQL en nuestra configuración de ejemplo, my.cnf debe tener este aspecto:

[MYSQLD]                        # Options for mysqld process:
ndbcluster                      # run NDB engine
ndb-connectstring=192.168.0.10  # location of MGM node

[MYSQL_CLUSTER]                 # Options for ndbd process:
ndb-connectstring=192.168.0.10  # location of MGM node

Tras introducir lo anterior, guarde este fichero y salga del editor de texto. Hágalo pra las máquinas que guarden el nodo de datos "A", el "B" y el nodo SQL.

Configuración del nodo de administración

El primer paso al configurar el nodo MGM es crear el directorio en que puede encontrarse el fichero de configuración y crear el fichero própiamente dicho. Por ejemplo (ejecutando como root):

mkdir /var/lib/mysql-cluster
cd /var/lib/mysql-cluster
vi config.ini

Mostramos vi para crear el fichero, pero puede usar cualquier editor de textos.

Para nuestra inicialización representativa, el fichero config.ini debe leerse así:

[NDBD DEFAULT]    # Options affecting ndbd processes on all data nodes:
NoOfReplicas=2    # Number of replicas
DataMemory=80M    # How much memory to allocate for data storage
IndexMemory=18M   # How much memory to allocate for index storage
                  # For DataMemory and IndexMemory, we have used the
                  # default values. Since the "world" database takes up
                  # only about 500KB, this should be more than enough for
                  # this example Cluster setup.

[TCP DEFAULT]     # TCP/IP options:
portnumber=2202   # This the default; however, you can use any
                  # port that is free for all the hosts in cluster
                  # Note: It is recommended beginning with MySQL 5.0 that
                  # you do not specify the portnumber at all and simply allow
                  # the default value to be used instead

[NDB_MGMD]                      # Management process options:
hostname=192.168.0.10           # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster  # Directory for MGM node logfiles

[NDBD]                          # Options for data node "A":
                                # (one [NDBD] section per data node)
hostname=192.168.0.30           # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for this data node's datafiles

[NDBD]                          # Options for data node "B":
hostname=192.168.0.40           # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for this data node's datafiles

[MYSQLD]                        # SQL node options:
hostname=192.168.0.20           # Hostname or IP address
datadir=/usr/local/mysql/data   # Directory for SQL node's datafiles
                                # (additional mysqld connections can be
                                # specified for this node for various
                                # purposes such as running ndb_restore)

(NOTA: La base de datos "world" puede descargarse desde http://dev.mysql.com/doc/ donde puede encontrarse en "Examples".)

Una vez que todos los ficheros de configuración se han creado y se han especificado estas opciones, está preparado para arrancar el cluster y verificar que todos los procesos están en ejecución. Se discute acreca de esto en Sección 16.3.4, “Arranque inicial”.

Para información más detallada acerca de los parámetros de configuración de MySQL Cluster y sus usos, consulte Sección 16.4.4, “Fichero de configuración” y Sección 16.4, “Configuración de MySQL Cluster”. Para configuración de MySQL Cluster para realizar copias de seguridad, consulteSección 16.6.4.4, “Configuración para copias de seguridad de un nodo”.

Nota: El puerto por defecto para administración del cluster es 1186; el puerto por defecto para nodos de datos es 2202. A partir de MySQL 5.0.3, esta restricción se elimina, y el cluster reserva los puertos de los nodos de datos automáticamente de los que están libres.

16.3.4. Arranque inicial

Arrancar el cluster no es complicado una vez configurado. Cada proceso de los nodos del cluster debe arrancarse separadamente, y en la máquina en que reside. Mientras es posible arrancar los nodos en cualquier orden, seguidos por los nodos de almacenamiento y finalmente por los nodos SQL:

En la máquina de administración, realice el siguiente comando del shell del sistema para arrancar los procesos del nodo MGM:
```
  shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
```
Tenga en cuenta que ndb_mgmd debe saber dónde encontrar su fichero de configuración , usando la opción -f o --config-file . (Consulte Sección 16.5.3, “El proceso del servidor de administraciónndb_mgmd” para más detalles.)
En cada equipo de los nodos de datos, ejecute este comando para arrancar el proceso NDBD por primera vez:
```
  shell> ndbd --initial
```
Tenga en cuenta que es muy imporante usar el parámetro --initial sólo al arrancar ndbd por primera vez, o tras reiniciar tras una copia de seguridad/restauración o cambio de configuración. Esto es debido a que este parámetro hará que el nodo borre cualquier fichero creado por instancias ndbd anteriormente necesarios para la restauración, incluyendo el fichero log de restauración.
En la máquina cluster donde reside el nodo SQL, ejecute un mysqld normal como se muestra:
```
  shell> mysqld &
```

Si todo ha ido bien, y el cluster se ha inicializado correctamente, el cluster debería ser operacional. Puede comprobarlo invocando el nodo cliente de administración ndb_mgm ; la salida debe parecerse a la que hay a continuación:

shell> ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=2    @192.168.0.30  (Version: 5.0.11, Nodegroup: 0, Master)
id=3    @192.168.0.40  (Version: 5.0.11, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.0.10  (Version: 5.0.11)

[mysqld(SQL)]   1 node(s)
id=4   (Version: 5.0.11)

Puede encontrar ligeras diferencias en función de la versión exacta de MySQL que use.

Nota: Si usa una versión antigua de MySQL, puede ver el nodo SQL referenciado como '[mysqld(API)]'. Esto refleja un uso antiguo que ya está obsoleto.

Debería ser capaz de trabajar con bases de datos, tablas y datos en MySQL Cluster. ConsulteSección 16.3.5, “Cargar datos de ejemplo y realizar consultas” para una breve discusión.

16.3.5. Cargar datos de ejemplo y realizar consultas

Trabajar don datos en MySQL Cluster no es muy distinto que trabajar con MySQL sin Cluster. Hay que tener en cuenta dos puntos al hacerlo:

Las tablas deben crearse con la opción ENGINE=NDB o ENGINE=NDBCLUSTER , o cambiarse (medianteALTER TABLE) para usar el motor NDB CLuster para que puedan replicarse en el cluster. Si está importando tablas de una base de datos existente usando la salida de mysqldump, puede abrir el script SQL en un editor de texto y añadir está opción a cualquier comando de creación de tablas, o reemplazar cualquier opción ENGINE (o TYPE) existente con alguna de estas. Por ejemplo, suponga que tiene la base de datos de ejemplo world en otro MySQL server (que no soporta MySQL Cluster), y desea exportar la definición de la tabla City :
```
  shell> mysqldump --add-drop-table world City > city_table.sql
```
El fichero city_table.sql resultante contendrá el comando de creación de la tabla ( y el comandoINSERT necesario para importar los datos de la tabla):
```
  DROP TABLE IF EXISTS City;
  CREATE TABLE City (
  ID int(11) NOT NULL auto_increment,
  Name char(35) NOT NULL default '',
  CountryCode char(3) NOT NULL default '',
  District char(20) NOT NULL default '',
  Population int(11) NOT NULL default '0',
  PRIMARY KEY  (ID)
  ) TYPE=MyISAM;

  INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
  INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
  INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
  # (remaining INSERT statements omitted)
```
Necesitará asegurarse que MySQL usa el motor NDB para esta tabla. Hay dos formas de hacerlo. Una es, antes de importar la tabla en la base de datos del cluster, modificar su definición para que lea (usando City como ejemplo):
```
DROP TABLE IF EXISTS City;
CREATE TABLE City (
ID int(11) NOT NULL auto_increment,
Name char(35) NOT NULL default '',
CountryCode char(3) NOT NULL default '',
District char(20) NOT NULL default '',
Population int(11) NOT NULL default '0',
PRIMARY KEY  (ID)
) ENGINE=NDBCLUSTER;

INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
# (etc.)
```
Esto debe hacerse para la definición de cada tabla que será parte de la base de datos clusterizada. La forma más fácil de hacerlo es símplemente hacer un buscar y reemplazar en el fichero world.sql y reemplazar todas las instancias de TYPE=MyISAM con ENGINE=NDBCLUSTER. Si no quiere modificar el fichero, puede usar ALTER TABLE; consulte a continuación las particularidades.

Asumiendo que ha creado la base de datos llamada world en el nodo SQL del cluster, puede usar el cliente de línea de comandos mysql para leer city_table.sql, y crear y llenar de datos la tabla correspondiente de la forma usual:
```
shell> mysql world < city_table.sql
```
Es muy importante recordar que el comando anterior debe ejecutarse en la máquina en que corre el nodo SQL -- en este caso, la máquina con dirección IP 192.168.0.20.

Para crear una copia de la base de datos world en el nodo SQL, guarde el fichero en/usr/local/mysql/data, luego ejecute
```
shell> cd /usr/local/mysql/data
shell> mysql world < world.sql
```
Por supuesto, el script SQL debe ser leíble por el usuario mysql . Si guarda el fichero en un lugar distinto, ajuste lo anterior correctamente.

Es importante tener en cuenta que NDB Cluster en MySQL 5.0 no soporta descubrimiento automático de bases de datos. (Consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster”.) Esto significa que , una vez que la base de datos world y sus tablas se han creado en un nodo de datos, necesitará ejecutar el comando CREATE DATABASE world; (a partir de MySQL 5.0.2, puede usar CREATE SCHEMA world; en su lugar), seguido por FLUSH TABLES; en cada nodo de datos del cluster. Esto hará que el nodo reconozca la base de datos y lea sus definiciones de tablas.

Ejecutar consultas SELECT en el nodo SQL no es distinto a ejecutarlas en cualquier otra instancia de un MySQL server. Para ejecutar consultas de línea de comandos, primero necesita loguearse en el MySQL Monitor normalmente:
```
shell> mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.9-max

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

mysql>
```
Si no modifica las cláusulas ENGINE= en las definiciones de tabla antes de importar el script SQL, debe ejecutar los siguientes comandos en este punto:
```
mysql> USE world;
mysql> ALTER TABLE City ENGINE=NDBCLUSTER;
mysql> ALTER TABLE Country ENGINE=NDBCLUSTER;
mysql> ALTER TABLE CountryLanguage ENGINE=NDBCLUSTER;
```
Tenga en cuenta que símplemente usamos la cuenta root por defecto del sistema con una contraseña vacía. Por supuesto, en un sistema de producción, debe siempre seguir las precauciones de seguridad para instalar un MySQL server, incluyendo una contraseña de root y la creación de una cuenta de usuario con sólo los permisos necesarios para realizar las tareas necesarias para ese usuario. Para más información acerca de esto, consulte Sección 5.6, “El sistema de privilegios de acceso de MySQL”.

Vale la pena tener en cuenta que los nodos del cluster no utilizan el sistema de permisos de MySQL al acceder el uno al otro, y preparar o cambiar las cuentas de usuario de MySQL (incluyendo la cuentaroot ) no tiene efecto en la interacción entre nodos, sólo en aplicaciones accediendo al nodo SQL.

Seleccionar una base de datos y ejecutar una consulta SELECT contra una tabla en la base de datos se realiza de la forma normal, como salir del MySQL Monitor:
```
mysql> USE world;
mysql> SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;
+-----------+------------+
| Name      | Population |
+-----------+------------+
| Bombay    |   10500000 |
| Seoul     |    9981619 |
| São Paulo |    9968485 |
| Shanghai  |    9696300 |
| Jakarta   |    9604900 |
+-----------+------------+
5 rows in set (0.34 sec)

mysql> \q
Bye

shell>
```
Las aplicaciones usando MySQL pueden usar APIs estándar. Es importante recordar que sus aplicaciones deben acceder al nodo SQL, y no al nodo MGM o a los de almacenamiento. Este breve ejemplo muestra cómo puede ejecutar la misma consulta que la anterior usando la extensión de PHP 5mysqli ejecutando un servidor web en cualquier punto de la red:
```
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type"
        content="text/html; charset=iso-8859-1">
  <title>SIMPLE mysqli SELECT</title>
</head>
<body>
<?php
  # connect to SQL node:
  $link = new mysqli('192.168.0.20', 'root', '', 'world');
  # parameters for mysqli constructor are:
  #   host, user, password, database

  if( mysqli_connect_errno() )
    die("Connect failed: " . mysqli_connect_error());

  $query = "SELECT Name, Population
            FROM City
            ORDER BY Population DESC
            LIMIT 5";

  # if no errors...
  if( $result = $link->query($query) )
  {
?>
<table border="1" width="40%" cellpadding="4" cellspacing ="1">
  <tbody>
  <tr>
    <th width="10%">City</th>
    <th>Population</th>
  </tr>
<?
    # then display the results...
    while($row = $result->fetch_object())
      printf(<tr>\n  <td align=\"center\">%s</td><td>%d</td>\n</tr>\n",
              $row->Name, $row->Population);
?>
  </tbody
</table>
<?
  # ...and verify the number of rows that were retrieved
    printf("<p>Affected rows: %d</p>\n", $link->affected_rows);
  }
  else
    # otherwise, tell us what went wrong
    echo mysqli_error();

  # free the result set and the mysqli connection object
  $result->close();
  $link->close();
?>
</body>
</html>
```
Suponemos que el proceso ejecutándose en el servidor web puede alcanzar la IP del nodo SQL.

De forma parecida, puede usar la MySQL C API, Perl-DBI, Python-mysql, o los conectores propios de MySQL AB para realizar las tareas de definición y manipulación de datos como haría normalmente con MySQL.
Recuerde que cada tabla NDB debe tener una clave primaria. Si no se define clave primaria por el usuario cuando se crea la tabla, el motor NDB Cluster creará una oculta automáticamente. (Nota: esta clave oculta ocupa espacio como cualquier otro índice de tabla. No es raro encontrar problemas debido a espacio insuficiente en memoria para guardar estos índices creados automáticamente.)

16.3.6. Apagado y encendido seguros

Para parar el cluster símplemente introduzca lo siguiente en una shell en la máquina con el nodo MGM :

shell> ndb_mgm -e shutdown

Esto hará que ndb_mgm, ndb_mgmd, y cualquier proceso ndbd termine normalmente. Cualquier nodo SQL puede terminarse usando mysqladmin shutdown y otros medios. Tenga en cuenta que la opción -e aquí se usa para pasar un comando al cliente ndb_mgm desde el shell. Consulte Sección 4.3.1, “Usar opciones en la línea de comandos”.

Para reiniciar el cluster, símplemente ejecute estos comandos:

En el equipo de administración (192.168.0.10 en nuestra configuración):
```
  shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
```
En cada uno de los nodos de datos (192.168.0.30 y 192.168.0.40):
```
shell> ndbd
```
Recuerde de no invocar este comando con la opción --initial cuando reinicie el nodo NDBD normalmente.
Y en el equipo SQL (192.168.0.20):
```
shell> mysqld &
```

Para inforamción de hacer copias de seguridad de clusters, consulte Sección 16.6.4.2, “Usar el servidor de administración para crear una copia de seguridad”.

Para restaurar un cluster de una copia de seguridad requiere el uso del comando ndb_restore . Esto se trata en Sección 16.6.4.3, “Cómo restablecer una copia de seguridad de un nodo”.

Más información sobre la configuración del cluster MySQL puede encontrarse en Sección 16.4, “Configuración de MySQL Cluster”.

16.4. Configuración de MySQL Cluster

16.4.1. Generar MySQL Cluster desde el código fuente
16.4.2. Instalar el software
16.4.3. Rápido montaje de prueba de MySQL Cluster
16.4.4. Fichero de configuración

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 NDB Cluster . Este motor también se conoce símplemente como NDB, y las dos formas del nombre son sinónimas.

Para evitar reserva innecesaria de recursos, el servidor se configura por defecto con el motor NDBdesactivado. Para activar NDB, necesitará configurar el fichero de configuración my.cnf del servidor con la opción --ndbcluster .

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 localhost. Sin embargo, puede necesitar especificar su localización donde se encuentre, esto puede hacerse en my.cnf o en la línea de comandos del servidor MySQL. Antes de poderse usar el NDB, 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

NDB, 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 --with-ndbcluster 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. (ConsulteCapí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 ficheromy.cnf 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 /var/lib/mysql-cluster, ejecutando el siguiente comando como root del sistema:

shell> mkdir /var/lib/mysql-cluster

En este directorio, cree un fichero llamado config.ini con la siguiente información, substituyendo los valores apropiados por HostName y DataDir 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 --initial :

shell> ndbd --initial

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

shell> ndbd

Esto es porque la opción --initial 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 localhost en el puerto 1186.

Nota: Si ha instalado MySQL desde un tarball binario, necesitará especificar la ruta de los servidoresndb_mgmd y ndbd explícitamente. (Normalemnte, se encuentran en /usr/local/mysql/bin.)

Finalmente, vaya al directorio de datos de MySQL (usualmente /var/lib/mysql o/usr/local/mysql/data), y asegúrese que el fichero my.cnf 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 vemysql ended, chequee el fichero .err 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 ENGINE=NDBCLUSTER o su alias ENGINE=NDB.

16.4.4. Fichero de configuración

16.4.4.1. Ejemplo de configuración para MySQL Cluster
16.4.4.2. El connectstring de MySQL Cluster
16.4.4.3. Definir los equipos que forman un cluster MySQL
16.4.4.4. Definición del servidor de administración de MySQL Cluster
16.4.4.5. Definir los nodos de MySQL Cluster
16.4.4.6. Definir los servidores MySQL (nodos sql) en un MySQL Cluster
16.4.4.7. Conexiones TCP/IP de MySQL Cluster
16.4.4.8. Conexiones TCP/IP de MySQL Cluster usando conexiones directas
16.4.4.9. Conexiones de MySQL Cluster que comparten memoria
16.4.4.10. Conexiones de transporte SCI en MySQL Cluster

Configurar MySQL Cluster requiere trabajar con dos ficheros:

my.cnf: 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.
config.ini: 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.config.ini 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 my.cnf como se muestra en el siguiente ejemplo. Tenga en cuenta que las opciones mostradas aquí no deben confundirse con las de los ficherosconfig.ini . 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 connectstring 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 [mysql_cluster] en el cluster my.cnf 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 config.ini por defecto . Lo leendb_mgmd al arrancar y puede situarse en cualquier sitio. Su localización y nombre se especifican usando --config-file=[<path>]<filename> 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 config.ini localizado en el directorio de trabajo actual.

Los valores por defecto se definen para la mayoría de parámetros, y pueden especificarse enconfig.ini. Para crear una sección de valores por defecto, añada la palabra DEFAULT al nombre de sección. Por ejemplo, los nodos de datos se configuran usando las secciones [NDBD]. 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 [NDBD DEFAULT] que contenga una línea con DataMemory 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:

[COMPUTER]: Define las máquinas del cluster.
[NDBD]: Define los nodos de datos del cluster.
[MYSQLD]: Define los nodos MySQL del cluster.
[MGM] o [NDB_MGMD]: Define el nodo de administración del cluster.
[TCP]: Define conexiones TCP/IP entre nodos en el cluster, siendo TCP/IP el protocolo de conexión por defecto.
[SHM]: Define conexiones de memoria compartida entre nodos. Antiguamente, este tipo de conexión estaba disponible sólo en binarios compilados con la opción --with-ndb-shm . 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 config.ini. 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 DEFAULT 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 `connectstring` 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>]

<id> es un entero mayor que 1 que identifica un nodo en config.ini <port> es un entero que se refiere a un puerto unix regular <host> 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 localhost:1186 como valor connectstring por defecto si no se especifica otro. Si se omite <port> 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 (consultehttp://www.iana.org/assignments/port-numbers para más detalles).

Listando múltiples valores <host-specification> , 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 [mysql_cluster] en el fichero del servidor de administración my.cnf.
Para compatibilidad con versiones anteriores, hay dos otras opciones disponibles, usando la misma sintaxis:
1. Inicialice la variable de entorno NDB_CONNECTSTRING para que contenga el connectstring.
2. Escriba el connectstring para cada ejecutable en un fichero de texto llamado Ndb.cfg 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 my.cnf para cada ejecutable.

16.4.4.3. Definir los equipos que forman un cluster MySQL

La sección [COMPUTER] 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.

[COMPUTER]Id

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

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 [NDB_MGMD] (o su alias [MGM]) 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 ExecuteOnComputer ni HostName están presentes, se asume para ambos el valor por defecto localhost .

[NDB_MGMD]Id

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.
[NDB_MGMD]ExecuteOnComputer

Esto se refiere a una de las máquinas definidas en la sección [COMPUTER] .
[NDB_MGMD]PortNumber

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.
[NDB_MGMD]LogDestination

Este parámetro especifica dónde enviar la información de logueo del cluster. Hay tres opciones al respecto: CONSOLE, SYSLOG, y FILE:
- CONSOLE envía el log a stdout:
```
CONSOLE
```
- SYSLOG envía el log a un syslog , siendo los valores posibles uno de auth, authpriv, cron, daemon,ftp, kern, lpr, mail, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5,local6, o local7.
  
  Nota: No todos los dispositivos son soportadas necesariamente por cada sistema operativo.
```
SYSLOG:facility=syslog
```
- FILE 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:
  - filename: Nombre del fichero de log.
  - maxsize: 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 .x al nombre del fichero, donde xes el siguiente número no usado todavía por este nombre.
  - maxfiles: 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 FILE esFILE:filename=ndb_<id>_cluster.log,maxsize=1000000,maxfiles=6, donde <id> es el ID del nodo.
[NDB_MGMD]ArbitrationRank

Este parámetro se usa para definir qué nodos pueden actuar como árbitros. Sólo los nodos MGM y SQL pueden serlo. ArbitrationRank puede tener uno de los siguientes valores:
- 0: El nodo nunca se usará como árbitro.
- 1: El nodo tiene alta prioridad, esto es, será preferido como árbitro sobre los nodos con baja prioridad.
- 2: 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 poniendoArbitrationRank a 1 (el valor por defecto) y todos los nodos SQL a 0.
[NDB_MGMD]ArbitrationDelay

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.
[NDB_MGMD]DataDir

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 FILE para[NDB_MGMD]LogDestination como se discute préviamente en esta sección.)

16.4.4.5. Definir los nodos de MySQL Cluster

La sección [NDBD] 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 ExecuteOnComputer o HostName.
El parámetro NoOfReplicas

Se tienen que definir en la sección [NDBD DEFAULT] .

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

Identificar nodos de datos

El valor Id (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 k, M, o G como sufijo para indicar unidades de 1024, 1024*1024, o 1024*1024*1024. (Por ejemplo, 100k significa 100 * 1024 = 102400.) Los parámetros y valores son sensibles a mayúsculas.

[NBDB]Id

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.
[NDBD]ExecuteOnComputer

Se refiere a uno de las máquinas (equipos) definidos en la sección COMPUTER .
[NDBD]HostName

Especificar este parámetro tiene un efecto similar a especificar ExecuteOnComputer. Define el nombre de equipo de la máquina en que reside el nodo de almacenamiento. Este parámetro oExecuteOnComputer es necesario para especificar un nombre de equipo distinto a localhost.
(OBSOLETO) [NDBD]ServerPort

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.
[NDBD]NoOfReplicas

Este parámetro global sólo puede cambiarse en la sección [NDBD DEFAULT] , 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 NoOfReplicas 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 SHOW .

No hay valor por defecto para NoOfReplicas; el valor máximo posible es 4.
[NDBD]DataDir

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

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 DataDir.Nota: Este directorio debe existir antes de inciar el proceso ndbd.

La jerarquía de directorio recomendada para MySQL Cluster incluye /var/lib/mysql-cluster, 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 ndb_2_fs.
[NDBD]BackupDataDir

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

Memoria de datos e índice

DataMemory y IndexMemory 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 DataMemory y IndexMemory , ya que usualmente necesitan actualizarse para reflejar el uso real del cluster:

[NDBD]DataMemory

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 DataMemory se usa para almacenar los registros y los índices. Cada registro tiene una longitud fija . (Incluso columnas VARCHAR 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 DataMemory 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 porIndexMemory, pero no es así: sólo claves primarias e índices hash únicos usan esta memoria; los índices ordenados usan la memoria almacenada por DataMemory. 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 especifiqueUSING HASH en el comando de creación del índice. Esto puede verificarse ejecutando ndb_desc -ddb_name table_name en el cliente de administración.

El espacio de memoria reservado por DataMemory 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 NoOfReplicas. 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 DataMemory también contiene información UNDO: Para cada actualización, se reserva una copia de los registros no alterados en DataMemory. 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 DataMemory 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.
[NDBD]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. 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 paraIndexMemory y DataMemory 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*DataMemory para cada nodo de datos.

Se recomienda que DataMemory y IndexMemory 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.

DataMemory y IndexMemory 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 IndexMemory 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.MaxNoOfConcurrentTransactions es el número de transacciones posibles en un nodo;MaxNoOfConcurrentOperations es el número de registros que pueden estar en fase de actualización o bloqueados simultáneamente.

Ambos parámetros (especialmente MaxNoOfConcurrentOperations) 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.

[NDBD]MaxNoOfConcurrentTransactions

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.
[NDBD]MaxNoOfConcurrentOperations

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. MaxNoOfConcurrentOperations 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.
[NDBD]MaxNoOfLocalOperations

Por defecto, este parámetro se calcula como 1.1 * MaxNoOfConcurrentOperations 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.

[NDBD]MaxNoOfConcurrentIndexOperations

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ámetroMaxNoOfConcurrentOperations.

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.
[NDBD]MaxNoOfFiredTriggers

El valor por defecto de MaxNoOfFiredTriggers 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.
[NDBD]TransactionBufferMemory

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 ZATTRBUF_FILESIZE (que se encuentra enndb/src/kernel/blocks/Dbtc/Dbtc.hpp) es 4000*128 bytes (500KB). Un buffer similar para información de claves, ZDATABUF_FILESIZE (también en Dbtc.hpp) contiene 4000*16 = 62.5KB de tamaño de búffer. Dbtc es el módulo que trata la coordinación de transacciones.

Escaneos y búffering

Hay parámtros adicionales en el módulo Dblqh (en ndb/src/kernel/blocks/Dblqh/Dblqh.hpp) que afecta a lecturas y actualizaciones. Incluyen ZATTRINBUF_FILESIZE, por defecto 10000*128 bytes (1250KB) y ZDATABUF_FILE_SIZE, 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 TransactionBufferMemory es 1MB.

[NDBD]MaxNoOfConcurrentScans

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 MaxNoOfConcurrentScans 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 MaxNoOfConcurrentScans 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 deMaxNoOfConcurrentScans y el número de nodos de datos en el sistema.
[NDBD]MaxNoOfLocalScans

Especifica el número de registros de escaneo locales si varios escaneos no están paralelizados completamente.
[NDBD]BatchSizePerLocalScan

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 ScanBatchSize definido en los nodos SQL.
[NDBD]LongMessageBuffer

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

[NDBD]NoOfFragmentLogFiles

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 NoOfFragmentLogFiles 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 Out of log file space temporarily. Esta condición prevalecerá hasta que se complete un checkpoint y se mueva la cola de log.
[NDBD]MaxNoOfSavedMessages

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.

[NDBD]MaxNoOfAttributes

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.
[NDBD]MaxNoOfTables

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 BLOB se usa una tabla extra para almacenar la mayoría de datos BLOB . 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.
[NDBD]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.

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

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 USING HASH al definir el índice único.

El valor por defecto es 64. Cada índice consume aproximadamente 15KB por nodo.
[NDBD]MaxNoOfTriggers

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 índiceordenado 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.
[NDBD]MaxNoOfIndexes

Este parámetro está obsoleto en MySQL 5.0; debe usar MaxNoOfOrderedIndexes yMaxNoOfUniqueHashIndexes 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 TRUE poniéndolos a 1 o Y, y como FALSE poniéndolos a0 o N.

[NDBD]LockPagesInMainMemory

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.
[NDBD]StopOnError

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.
[NDBD]Diskless

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 Diskless a 1 o Y. Diskless está desactivado por defecto.
[NDBD]RestartOnErrorInsert

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.

[NDBD]TimeBetweenWatchDogCheck

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).
[NDBD]StartPartialTimeout

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). 0 significa timeout eterno; en otras palabras, el cluster puede arrancar sólo si todos los nodos están disponibles.
[NDBD]StartPartitionedTimeout

Si el cluster está preparado para arrancar tras esperar durante StartPartialTimeout 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).
[NDBD]StartFailureTimeout

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 0 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.
[NDBD]HeartbeatIntervalDbDb

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.
[NDBD]HeartbeatIntervalDbApi

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

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..
[NDBD]TimeBetweenLocalCheckpoints

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 * 2²⁰) 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. PonerTimeBetweenLocalCheckpoints a 6 o menos significa que los checkpoints locales se ejecutarán contínuamente sin pausa, independientemente de la carga de trabajo del cluster.
[NDBD]TimeBetweenGlobalCheckpoints

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.
[NDBD]TimeBetweenInactiveTransactionAbortCheck

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).
[NDBD]TransactionInactiveTimeout

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.
[NDBD]TransactionDeadlockDetectionTimeout

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).
[NDBD]NoOfDiskPagesToDiskAfterRestartTUP

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, ponerNoOfDiskPagesToDiskAfterRestartTUP 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ámetrosNoOfDiskPagesToDiskAfterRestartACC. (Consulte la entrada para IndexMemory 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 NoOfFragmentLogFiles, DataMemory, y IndexMemory.

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

Este parámetro usa las mismas unidades que NoOfDiskPagesToDiskAfterRestartTUP 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).
[NDBD]NoOfDiskPagesToDiskDuringRestartTUP

Este parámero parecido a NoOfDiskPagesToDiskAfterRestartTUP yNoOfDiskPagesToDiskAfterRestartACC, 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).
[NDBD]NoOfDiskPagesToDiskDuringRestartACC

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 NoOfDiskPagesToDiskAfterRestartTUP y NoOfDiskPagesToDiskAfterRestartACC, 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).
[NDBD]ArbitrationTimeout

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.

[NDBD]UndoIndexBuffer

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 677Index UNDO buffers overloaded.
[NDBD]UndoDataBuffer

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 Data UNDO buffers overloaded.
[NDBD]RedoBuffer

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 REDO log buffers overloaded.

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 stdout. 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 stdout; 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 stdout, 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.

[NDBD]LogLevelStartup

Reportar niveles para eventos generados durante el arranque del proceso.

El nivel por defecto es 1.
[NDBD]LogLevelShutdown

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

El nivel por defecto es 0.
[NDBD]LogLevelStatistic

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.
[NDBD]LogLevelCheckpoint

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

El nivel por defecto es 0.
[NDBD]LogLevelNodeRestart

Nivel de reporte para eventos generados durante reinicio de nodo.

El nivel por defecto es 0.
[NDBD]LogLevelConnection

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

El nivel por defecto es 0.
[NDBD]LogLevelError

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.
[NDBD]LogLevelInfo

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.

[NDBD]BackupDataBufferSize

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 BackupWriteSize (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.
[NDBD]BackupLogBufferSize

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.
[NDBD]BackupMemory

Este parámetro es la suma de BackupDataBufferSize y BackupLogBufferSize.

El valor por defecto es 2MB + 2MB = 4MB.
[NDBD]BackupWriteSize

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 [MYSQLD] del fichero config.ini 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.

[MYSQLD]Id

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.
[MYSQLD]ExecuteOnComputer

Se refiere a una de las máquinas definidas en la sección [COMPUTER] del fichero de configuración.
[MYSQLD]ArbitrationRank

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 ArbitrationRank a 1 (por defecto) y los nodos SQL a 0.
[MYSQLD]ArbitrationDelay

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.
[MYSQLD]BatchByteSize

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 (BatchSize) y en términos de bytes (BatchByteSize). 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.
[MYSQLD]BatchSize

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

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 NodeId1, NodeId2, y los parámetros a cambiar.

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

[TCP]NodeId1 , [TCP]NodeId2

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

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.
[TCP]SendSignalId

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

Este parámetro es booleano (Y/N o 1/0) , 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.
[TCP]PortNumber

(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.
[TCP]ReceiveBufferMemory

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 [TCP] del fichero config.ini 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 172.23.72.* 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 IP1.1.0.* 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 -max se compila usando --with-ndb-shm.) Cuando se define la memoria compartida explícitamente como método de conexión, es necesario definir como mínimo NodeId1, NodeId2 y ShmKey. 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.

[SHM]NodeId1, [SHM]NodeId2

Para identificar una conexión entre dos nodos es necesario proporcionar identificadores para cada uno de ellos como NodeId1 y NodeId2.
[SHM]ShmKey

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.
[SHM]ShmSize

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 defineShmSize. El valor por defecto es 1MB.
[SHM]SendSignalId

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 Y hace que los IDs de mensajes se transporten sobre la red también. Esta característica está desactivada por defecto.
[SHM]Checksum

Este parámetro es Y/N , 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 --with-ndb-sci=/your/path/to/SCI. El path debe apuntar a un directorio que contiene como mínimo los directorios lib y include 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 procesosndbd . Al menos debe haber 1 CPU por proceso ndbd , con al menos 1 CPU en reserva para tratar actividades del sistema operativo.

[SCI]NodeId1, [SCI]NodeId2

Para identificar una conexión entre dos nodos es necesario proporcionar identificadores de nodo para cada uno de ellos, como NodeId1 y NodeId2.
[SCI]Host1SciId0

Esto identifica el nodo ID SCI en el primer nodo del Cluster (identificado por NodeId1).
[SCI]Host1SciId1

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.
[SCI]Host2SciId0

Esto identifica el ID del nodo SCI en el segundo nodo del Cluster (identificado por NodeId2).
[SCI]Host2SciId1

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

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.
[SCI]SendLimit

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.
[SCI]SendSignalId

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

Este parámetro es un valor booleano, y está desactivado por defecto. Cuando Checksum 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.

16.5. Gestión de procesos en MySQL Cluster

16.5.1. El uso del proceso del servidor MySQL para MySQL Cluster
16.5.2. ndbd, el proceso del nodo de motor de almacenamiento
16.5.3. El proceso del servidor de administración ndb_mgmd
16.5.4. El proceso de cliente de administración ndb_mgm
16.5.5. Opciones de comando para procesos de MySQL Cluster

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

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

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

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

Use --ndbcluster como opción de arranque para mysqld

Inserte una línea con ndbcluster en la sección [mysqld] en el fichero my.cnf .

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

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

El ID del nodo del servidor MySQL.
El nombre de equipo o dirección IP para el servidor de administración (nodo MGM).
El puerto en el que puede conectarse al servidor de administración.

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

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

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

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

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

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

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

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

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

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

ndb_<NodeID>_error.log es un fichero que contiene registros de todas las caídas que ha encontrado el proceso referenciado ndbd. Cada registro en este fichero contiene un breve mensaje de error y una referencia a un fichero de traceo para este fallo. Una entrada típica en este fichero puede ser parecida a:
```
Date/Time: Saturday 30 July 2004 - 00:20:01
Type of error: error
Message: Internal program error (failed ndbrequire)
Fault ID: 2341
Problem data: DbtupFixAlloc.cpp
Object of reference: DBTUP (Line: 173)
ProgramName: NDB Kernel
ProcessID: 14909
TraceFile: ndb_2_trace.log.2
***EOM***
```
ndb_<NodeID>_trace.log.<TraceID> es un fichero de traceo que describe exactamente qué ha ocurrido jusnto antes de que ocurra el error. Esta información es útil para su análisis por parte del equipo de desarrollo de MySQL Cluster .

Es posible configurar el número de estos ficheros de traceo que se crean antes que los ficheros antiguos se sobreescriban. <TraceID> es un número que se incrementa para cada fichero de traceo sucesivo.
ndb_<NodeID>_trace.log.next es el fichero que se encarga del siguiente número de traceo para fichero a asignar.
ndb_<NodeID>_out.log es un fichero que contiene cualquier salida de datos del proceso ndbd . Este fichero se crea sólo si ndbd se arranca como demonio.
ndb_<NodeID>.pid es un fichero que contiene el ID de proceso del proceso ndbd cuando se arranca como demonio. También funciona como fichero de bloqueo para evitar arrancar los nodos con el mismo identificador.
ndb_<NodeID>_signal.log es un fichero usado sólo en versiones de depuración de ndbd, donde es posible tracear toda la entrada, salida, y mensajes internos con sus datos en el proceso ndbd .

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

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

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

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

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

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

16.5.3. El proceso del servidor de administración ndb_mgmd

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

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

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

config.ini es el fichero de configuración para el cluster como un todo. Este fichero se crea por el usuario y lo lee el servidor de administración. La configuración de este fichero se discute enSección 16.4, “Configuración de MySQL Cluster”.
ndb_<NodeID>_cluster.log es el ficheor de log de eventos del cluster. Ejemplos de tales eventos incluyen inicio y finalización de checkpoints, eventos de arranque de nodos, fallos de nodos, y niveles de uso de memoria. Una lista completa de eventos de cluster con descripciones puede encontrarse enSección 16.6, “Administración de MySQL Cluster”.

Cuando el tamaño del log del cluster alcanza un millón de bytes el fichero se renombra andb_<NodeID>_cluster.log.SeqID, donde SeqID es el número de secuencia del fichero de log del cluster . (Por ejemplo: si 1,2, y 3 ya existen, el siguiente fichero de log se llamará con el número 4.)
ndb_<NodeID>_out.log es el fichero usado por stdout y stderr cuando se ejecuta el servidor de administración como demonio.
ndb_<NodeID>.pid es el fichero PID usado cuando se ejecuta el servidor de administración como demonio.

16.5.4. El proceso de cliente de administración ndb_mgm

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

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

shell> ndb_mgm localhost 1186

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

16.5.5. Opciones de comando para procesos de MySQL Cluster

16.5.5.1. Opciones de mysqld relacionadas con MySQL Cluster
16.5.5.2. Opciones de comando para ndbd
16.5.5.3. Opciones del comando ndb_mgmd
16.5.5.4. Opciones de comando para ndb_mgm

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

-?, --usage, --help

Muestra una pequeña lista con descripciones de las opciones de comandos disponibles.
-V, --version

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

connect_string Cambia la cadena de conexión del servidor de administración como opción de comando.
```
shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"
```
--debug[=options]

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

Puede usarse para enviar un comando al ejecutable cluster desde el shell de sistema. Por ejemplo, cualquiera de los siguientes comandos:
```
shell> ndb_mgm -e show
```
o
```
shell> ndb_mgm --execute="SHOW"
```
es equivalente a
```
NDB> SHOW;
```
Esto es análogo a cómo la opción -e funciona con el cliente de línea de comandos mysql . ConsulteSección 4.3.1, “Usar opciones en la línea de comandos”.

16.5.5.1. Opciones de mysqld relacionadas con MySQL Cluster

--ndbcluster

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

Desactiva el motor NDB Cluster. Esta opción está activa por defecto para binarios donde se incluye; en otras palabras, el motor NDB Cluster se desactiva hasta que se activa via --ndbcluster. Esta opción se activa sólo si el servidor se compiló con soporte para el motor NDB Cluster .
--ndb-connectstring=connect_string

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

16.5.5.2. Opciones de comando para ndbd

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

-d, --daemon

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

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

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

Un arranque --initial se usa sólo la primera vez que se arranca el proceso ndbd , y borra todos los ficheros del sistema de ficheros del cluster y recrea todos los ficheros de log REDO. Las excepciones a esta regla son:
- Cuando se realiza una actualización de software que cambia los contenidos de cualquier fichero.
- Al reiniciar el nodo con una nueva versión de ndbd.
- Como medida de última hora cuando por alguna razón el reinicio repetitivo del nodo o sistema fallan. En este caso el nodo no puede seguir usándose para restaurar datos debido a la destrucción de los ficheros de datos.
Esta opción no afecta ningún fichero de copia de seguridad que se ha creado por el nodo afectado.
--nostart

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

16.5.5.3. Opciones del comando ndb_mgmd

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

-f filename, --config-file=filename, (OBSOLETE): -c filename

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

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

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

16.5.5.4. Opciones de comando para ndb_mgm

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

[host_name [port_num]]

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

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

16.6. Administración de MySQL Cluster

16.6.1. Comandos del cliente de administración
16.6.2. Informes de eventos generados por MySQL Cluster
16.6.3. Modo de usuario único
16.6.4. Copias de seguridad On-line para MySQL Cluster

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

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

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

16.6.1. Comandos del cliente de administración

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

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

HELP

Muestra información de todos los comandos disponibles.
SHOW

Muestra informaicón del estado del cluster.
<id> START

Arranca el nodo de datos identificado por <id> (o todos los nodos de datos).
<id> STOP

Para el nodo de datos identificado por <id> (o todos los nodos de datos).
<id> RESTART [-N] [-I]

Reinicia el nodo de datos identificado por <id> (o todos los nodos de datos).
<id> STATUS

Muestra información de estado para el nodo de datos identificado por <id> (o todos los nodos de datos).
ENTER SINGLE USER MODE <id>

Entra en modo de usuario único, donde sólo el servidor MySQL identificado por el ID del nodo <id>tiene permiso para acceder a la base de datos.
EXIT SINGLE USER MODE

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

Termina el cliente de administración.
SHUTDOWN

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

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

16.6.2. Informes de eventos generados por MySQL Cluster

16.6.2.1. Registrar comandos de control
16.6.2.2. Registro de eventos

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

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

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

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

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

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

Categoría: Puede tener uno de los siguientes valores: STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT,NODERESTART, CONNECTION, ERROR, o INFO.
Prioridad: Representada por un número de 1 a 15 incluidos, donde 1 indica “más importante” y 15 “menos importante”.
Nivel de severidad: Puede ser uno de los siguientes valores: ALERT, CRITICAL, ERROR, WARNING,INFO, o DEBUG.

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

16.6.2.1. Registrar comandos de control

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

CLUSTERLOG ON

Activa el log del cluster.
CLUSTERLOG OFF

Desactiva el log del cluster
CLUSTERLOG INFO

Información acerca de la configuración del log del cluster.
<id> CLUSTERLOG <category>=<threshold>

Loguea eventos de category con prioridad menor o igual a threshold en el log del cluster.
CLUSTERLOG FILTER <severity>

Cambia a loguear eventos del cluster de la severity especificada.

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

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

Categoría	Umbral por defecto (todos los nodos de datos)
`STARTUP`	7
`SHUTDOWN`	7
`STATISTICS`	7
`CHECKPOINT`	7
`NODERESTART`	7
`CONNECTION`	7
`ERROR`	15
`INFO`	7

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

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

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

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

16.6.2.2. Registro de eventos

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

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

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

CONNECTION Eventos

Hay eventos asociados con conexiones entre nodos del cluster.

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

CHECKPOINT Eventos

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

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

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

STARTUP Eventos

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

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

NODERESTART Eventos

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

Evento	Prioridad	Nivel de severidad	Descripción
Fase de fallo de nodo completa	8	ALERT	Rerporta la finalización de las fases de fallo de nodo
El nodo ha fallado, el estado del nodo era `X`	8	ALERT	Reporta que el nodo ha fallado
Reporta el resultado del árbitro	2	ALERT	Hay 8 resultados distintos posibles de arbitraciones: Chequeo de arbitración fallido - quedan menos de 1/2 de los nodos. Chequeo de arbitración exitoso - mayoría de nodos del grupo. Chequeo de arbitración fallido - falta un grupo de nodos. Partición de red - arbitración necesaria Arbitración exitosa - respuesta afirmativa del nodo `X` Arbitración fallida - respuesta negativa del nodo `X` Partición de red - no hay árbitro disponible Partición de red - no hay árbitro configurado
Completada la copia de fragmento	10	INFO
Completada la copia de información de directorio	8	INFO
Completada la copia de información de distribución	8	INFO
Iniciada la copia de fragmentos	8	INFO
Completada la copia de todos los fragmentos	8	INFO
Control de GCP iniciado	7	INFO
Control de GCP completado	7	INFO
Control de LCP iniciado	7	INFO
Control de LCP completado (estado = `X`)	7	INFO
Reporta si se encuentra un árbitro o no	6	INFO	Hay 7 salidas distintas al buscar un árbitro: El servidor de administración reinicia el flujo árbitro [estado=`X`] Prepara nodo árbitro `X` [ticket=`Y`] Recibe nodo árbitro `X` [ticket=`Y`] Nodo árbitro iniciado `X` [ticket=`Y`] Nodo árbitro perdido `X` - proceso fallido [estado=`Y`] Lost arbitrator node `X` - process exit [state=`Y`] Nodo árbitro perido `X` <error msg> [estado=`Y`]

STATISTICS Eventos

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

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

ERROR Eventos

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

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

INFO Eventos

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

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

16.6.3. Modo de usuario único

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

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

Ejemplo:

NDB> ENTER SINGLE USER MODE 5

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

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

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

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

Ejemplo:

NDB> EXIT SINGLE USER MODE

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

1. Terminar todas las transacciones de modo de usuario único.
2. Ejecutar el comando EXIT SINGLE USER MODE
3. Reiniciar los nodos de datos del cluster

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

16.6.4. Copias de seguridad On-line para MySQL Cluster

16.6.4.1. Conceptos de copias de seguridad de nodos
16.6.4.2. Usar el servidor de administración para crear una copia de seguridad
16.6.4.3. Cómo restablecer una copia de seguridad de un nodo
16.6.4.4. Configuración para copias de seguridad de un nodo
16.6.4.5. Resolver problemas con copias de seguridad

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

16.6.4.1. Conceptos de copias de seguridad de nodos

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

Metadatos: nombres y definiciones de todas las tablas de la base de datos.
Registros de tabla: los datos guardados realmente en las tablas de la base de datos cuando se hizo la copia de seguridad
Log de transacción: un registro secuencial diciendo cómo y cuándo se han almacenado los datos en la base de datos.

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

BACKUP-<BackupId>.<NodeId>.ctl

Un fichero de control con información de control y metadatos. Cada nodo guarda las mismas definiciones de tabla (para todas las tablas en el cluster) en su propia versión de este fichero.
BACKUP-<BackupId>-0.<NodeId>.data

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

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

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

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

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

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

Arrancar el servidor de administración (ndb_mgm).
Ejecutar el comando START BACKUP.
El servidor de administración responderá con el mensaje “Start of backup ordered”. Esto significa que el servidor de administración ha enviado la petición al cluster, pero no ha recibido respuesta aun.
El servidor de administración responderá “Backup <BackupId> started”, donde <BackupId> es el identificador único para esta copia de seguridad. (Este ID se guardará en el log del cluster, si no ha sido configurado de otro modo.) Esto significa sólo que el cluster ha recibido y procesado la petición de copia de seguridad. Esto no significa que se haya completado.
El servidor de administración envía la señal que la copia ha finalizado con el mensaje “Backup<BackupId> completed”.

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

shell> ndb_mgm -e "START BACKUP"

Para abortar una copia en marcha:

Arranque el servidor de administración.
Ejecute el comando 'ABORT BACKUP <BackupId>'. El número <BackupId> es el identificador de la copia que se incluyó en la respuesta del servidor de administración cuando se inició la copia (en el mensaje '"Backup <BackupId> started"').
El servidor de administración reconocerá la petición de aborto con “Abort of backup <BackupId>ordered”; tenga en cuenta que no se ha recibido todavía respuesta a esta petición.
Una vez que la copia de seguridad se ha abortado, el servidor de administración reportará “Backup<BackupId> has been aborted for reason msg”. Esto significa que el cluster ha terminado la copia y que todos los ficheros relacionados con la misma se han eliminado del sistema de ficheros del cluster.

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

shell> ndb_mgm -e "ABORT BACKUP BackupId"

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

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

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

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

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

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

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

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

BackupDataBufferSize

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

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

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

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

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

16.6.4.5. Resolver problemas con copias de seguridad

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

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

16.7. Usar interconexiones de alta velocidad con MySQL Cluster

16.7.1. Configurar MySQL Cluster para que utilice Sockets SCI
16.7.2. Entender el impacto de interconexiones de nodos

Antes que comenzara el diseño de NDB Cluster en 1996, era evidente que uno de los mayores problemas que encontraríamos al construir bases de datos paralelas sería la comunicación entre los nodos de la red. Por esta razón, NDB Cluster se diseñó desde el comienzo para permitir el uso de un número de mecanismos de transporte distintos. En este manual, usamos el término transporter para ello.

Actualmente el código MySQL Cluster incluye soporte para 4 transportes distintos. La mayoría de usuarios usan TCP/IP sobre Ethernet ya que es ubicuo. Este también es el transporter más probado en MySQL Cluster.

Estamos trabajando para asegurar que la comunicación con el proceso ndbd se hace en “chucnks” tan grandes como sea posible ya que esto beneficia a todos los tipos de transimisión de datos.

Para los usuarios que lo deseen, también es posible usar interconexión de cluster para mejorar el rendimiento. Hay dos formas de hacerlo: puede diseñar un transporter a medida o puede usar implementaciones de socket que sobrepasen la pila TCP/IP de una forma u otra. Hemos expermientando con ambas técnicas usando la tecnología SCI (Scalable Coherent Interface) desarrollada por Dolphin.

16.7.1. Configurar MySQL Cluster para que utilice Sockets SCI

En esta secció mostraremos cómo se puede adaptar un cluster configurado para comunicación TCP/IP normal para que use SCI Sockets. Esta documentación se basa en SCI Sockets versión 2.3.0 de 01 Octubre 2004.

Prerequisitos

Cualquier máquina que quiera que use SCI Sockets necesita disponer de tarjetas SCI .

Es posible usar SCI Sockets con cualquier versión de MySQL Cluster. No se necesita ninguna compilación especial ya que usa llamadas de socket normales que están disponibles en MySQL Cluster. Sin embargo, SCI Sockets se soportan sólo en los kernels Linux 2.4 y 2.6 . SCI Transporters se ha probado con éxito en sistemas operativos adicionales aunque sólo lo hemos verificado con Linux 2.4 hasta ahora.

Esencialmente hay cuatro requerimientos para SCI Sockets:

Compilar las bibliotecas SCI Socket.
Instlara las bibliotecas del kernel SCI Socket.
Instalación de uno o dos ficheros de configuración.
La biblioteca de kernel SCI Socket debe estar activada para toda la máquina o para la shell en que se arranca el proceso MySQL Cluster.

Este proceso debe repetirse para cada máquina del cluster en que quiera usar SCI Sockets para comunicación entre nodos.

Necesita dos paquetes para que funcione SCI Sockets :

El paquete de código fuente con las bibliotecas de soporte DIS para las bibliotecas SCI Sockets .
El paquete de código fuente para las bibliotecas SCI Socket mismas.

Actualmente, estan disponible sólo en formato de código fuente. Las últimas versiones de estos paquetes al escribir esto están disponibles como (respectivamente)DIS_GPL_2_5_0_SEP_10_2004.tar.gz y SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz. Debería poder encontrar estas versiones (o posteriores) en http://www.dolphinics.no/support/downloads.html.

Instalación de paquetes

Una vez que tiene los paquetes con las bibliotecas, el siguiente paso es descomprimirlas en los directorios apropiados, con la biblioteca SCI Sockets en un directorio bajo el código DIS. Luego, necesita compilar las bibliotecas. Este ejemplo muestra los comandos usados en Linux/x86 para realizar esta tarea:

shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz
shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/
shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
shell> cd ../adm/bin/Linux_pkgs
shell> ./make_PSB_66_release

Es posible compilar estas bibliotecas para algunos procesadores 64-bit. Para compilar las bibliotecas para Opteron CPUs usando la extensión 64-bit , ejectue make_PSB_66_X86_64_release en lugar amake_PSB_66_release; si la compilación se hace en una máquina Itanium, debe usarmake_PSB_66_IA64_release. La variante X86-64 debe funcionar para arquitecturas Intel EM64T pero no se ha probado.

Una vez que se completa el proceso de compilación ,las bibliotecas compiladas se encuentran en un fichero tar zipeado con un nombre entre las líneas de DIS-<operating-system>-time-date. Es hora de instalar el paquete en el lugar apropiado. En este ejemplo lo guardaremos en /opt/DIS. (Nota: Seguramente necesitará ejecutar lo siguiente como root del sistema.)

shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/
shell> cd /opt
shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz
shell> mv DIS_Linux_2.4.20-8_181004 DIS

Configuración de red

Ahora que todos los binarios y bibliotecas están en su lugar adecuado, necesitamos asegurarnos que las tarjetas SCI tiene IDs de nodo adecuados en el espacio de direcciones SCI.

Es necesario decidir la estructura de red antes de seguir. Hay tres tipo de estructura de red que pueden usarse en este contexto:

Anillo simple unidimensional
Uno o más switches con un anilo para cada puerto de switch
Un toro de dos o tres dimensiones.

Cada una de estas topologías tiene su propio método para proporcionar Ids de nodo. Discutimos cada una de las mismas brévemente.

Un anillo simple usa IDs de nodo que son múltipes de 4 distintos a cero: 4, 8, 12,...

La siguiente posibilidad usa swithces SCI. Un switch SCI tiene 8 puertos, cada uno de los cuales puede soportar un anillo. Es necesario asegurarse que distintos anillos usan distintos espacios de nombres. En una configuración típica, el primer puerto usa IDs de nodo por debajo de 64 (4 - 60), el siguiente puerto los siguientes 64 IDs (68 - 124) , y así, con IDs de nodo 452 - 508 siendo asignados al octavo puerto.

Las estructuras de red de toro bi o tri dimensional se tienen en cuenta donde cada nodo se localiza en cada dimensión, incrementando en 4 para cada nodo en la primera dimensión, en 63 cada nodo en la segunda dimensión, y (donde sea aplicable) en 1024 en la tercera dimensión. Consulte Dolphin's Web site para más documentación.

En nuestras pruebasa hemos usado switches, aunque las instalaciones de cluster más grandes usan toros bi o tri dimensionales. La ventaja proporcionada por switches es que, con tarjetas SCI duales y switches duales, es posible constuir con facilidad relativa una red redundante donde el tiempo de fallo medio en la red SCI es del orden de 100 microsegundos. Esto lo soporta el transporte SCI en MySQL Cluster y también está bajo desarrollo par la implementación SCI Socket .

Evitar fallos en el toro 2D/3D es posible pero requiere el envío de nuevos índices de enrutamiento a todos los nodos. Sin embargo, esto requiere sólo 100 milisegundos o así para completarse y debería ser aceptable para la mayoría de casos de alta disponibilidad.

Situar los nodos de datos del cluster adecuadamente en la arquitectura de switch hace que sea posible usar 2 switches para construir una arquitectura en que puedan interconectarse 16 máquinas y que un fallo único no pueda afectar a más de una. Con 32 máquinas y 2 switches se puede configurar el cluster de forma que un fallo único no pueda causar la pérdida de más de dos nodos; en este caso es posible saber qué par de nodos está afectado. Por lo tanto, poner los dos nodos en grupos de nodos separados hace que la instalación de MySQL Cluster sea “segura” .

Para poner el ID de nodo en una tarjeta SCI use el siguiente comando en el directorio /opt/DIS/sbin. En este ejemplo -c 1 se refiere al número de la tarjeta SCI (siempre será 1 si sólo hay 1 tarjeta en la máquina) , -a 0 se refiere al adaptador 0, y 68 es el ID del nodo:

shell> ./sciconfig -c 1 -a 0 -n 68

Si tiene varias tarjetas SCI en la misma máquina, puede determinar qué tarjeta tiene cada slot ejecutando el siguiente comando (de nuevo asumimos que el directorio de trabajo actual es/opt/DIS/sbin):

shell> ./sciconfig -c 1 -gsn

Esto le retorna el número de serie de la tarjeta SCI. Luego repita este procedimiento con -c 2, y siga con cada tarjeta en la máquina. Una vez que ha relacionado cada tarjeta con cada slot, puede poner los IDs de nodo para todas las tarjetas.

Una vez instaladas la bibliotecas y binarios necesarios, y configurado el ID de nodo SCI, el siguiente paso es configurar el mapeo de nombres de equipo (o direcciones IP) con el ID del nodo SCI. Esto se realiza en el fichero de configuración de los sockets SCI, que debería encontrarse en/etc/sci/scisock.conf. En este fichero, cada nombre de máquina o dirección IP se mapea con el ID de nodo SCI. Aquí hay un ejemplo sencillo de un fichero de configuración:

#host           #nodeId
alpha           8
beta            12
192.168.10.20   16

Es posible limitar la configuración para que se aplique sólo a un subconjunto de los puertos disponibles para estos equipos. Un fichero de configuración adicional /etc/sci/scisock_opt.conf puede usarse para esto, como se muestra aquí:

#-key                        -type        -values
EnablePortsByDefault                yes
EnablePort                  tcp           2200
DisablePort                 tcp           2201
EnablePortRange             tcp           2202 2219
DisablePortRange            tcp           2220 2231

Instalación de drivers

Con los ficheros de configuración en su lugar, se pueden instalar los drivers.

Primero los drivers de bajo nivel y luego el driver del socket SCI:

shell> cd DIS/sbin/
shell> ./drv-install add PSB66
shell> ./scisocket-install add

Si se desea, la instalación puede chequearse invocando un script que verifica que todos los nodos en el los ficheros de configuración del socket SCI son accesibles:

shell> cd /opt/DIS/sbin/
shell> ./status.sh

Si descubre un error y necesita cambiar la configuración del socket SCI, es necesario usarksocketconfig para ello:

shell> cd /opt/DIS/util
shell> ./ksocketconfig -f

Testing y Setup

Para asegurar que los sockets SCI están siendo usados, puede emplear el programa de testeolatency_bench . Usando este componente del servidor de utilidades, los clientes pueden conectar con el servidor para testear la latencia de la conexión; determinar si el SCI está activado o no debe ser muy simple observando la latencia. (Nota: Antes de usar latency_bench, es necesario incializar la variable de entorno LD_PRELOAD como se muestra posteriormente.)

Para inicializar un servidor, use:

shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -server

Para ejecutar un cliente, use latency_bench de nuevo, excepto que esta vez con la opción -client :

shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client server_hostname

La configuración del socket SCI debería estar completa ahora y MySQL Cluster preparado para usar SCI Sockets y SCI transporter (consulte Sección 16.4.4.10, “Conexiones de transporte SCI en MySQL Cluster”).

Arrancar el Cluster

El siguiente paso en el proceso es arrancar MySQL Cluster. Para permitir el uso de SCI Sockets es necesario inicializar la variable de entorno LD_PRELOAD antes de arrancar ndbd, mysqld, y ndb_mgmd. Esta variable debe apuntar a la biblioteca kernel para SCI Sockets.

Para arrancar ndbd en un bash shell, haga:

bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so
bash-shell> ndbd

En un entorno tcsh se puede hacer lo mismo con:

tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so
tcsh-shell> ndbd

Nota: MySQL Cluster sólo puede usar la variante de kernel de SCI Sockets.

16.7.2. Entender el impacto de interconexiones de nodos

El proceso ndbd tiene un número de constructores simples que se usan para acceder a los datos en MySQL Cluster. Hemos creado un benchmark sencillo para comprobar el rendimiento de cada uno de ellos y los efectos en el rendimiento de varias interconexiones.

Hay cuatro métodos de acceso:

Acceso por clave primaria

Este es el acceso simple a un registro a través de su clave primaria. Es el caso más sencillo en que sólo se accede a un registro a la vez, que significa que el coste total de preparar un número de mensajes TCP/IP y un número de costes para cambio de contexto se envían mediante esta simple petición. En el caaso en que se envían accesos a varias claves primarias en un proceso batch estos accesos comparten el coste de preparar los mensajes TPC/IP necesarios y los cambios de contexto. Si los mensajes TCP/IP son para destinaciones distintas, se debe preparar mensajes adicionales.
Acceso por clave única

Son similares a los anteriores, con la excepción que los accesos por clave única se ejecutan como lecturas en una tabla índice seguidos por su acceso por clave primaria a la tabla. Sin embargo, sólo se envía una petición desde el servidor MySQL, y la lectura de la tabla índice es tratada por ndbd. Estas peticiones también se benefician del uso de batch.
Escaneo de toda la tabla

Cuando no existen índices para la búsqueda en una tabla, se realiza un escaneo completo. Se envía como petición úncia al proceso ndbd , que divide el escaneo de tabla en un conjunto de escaneos paralelos en todos los procesos ndbd del proceso. En futuras versiones de MySQL Cluster, un nodo SQL será capaz de filtrar algunos de estos escaneos.
Escaneo de rangos usando índices ordenados

Cuando se usa un índice ordenado, realiza un escaneo igual que lo hace un escaneo de tabla completo, excepto que escanea sólo los registros en el rango usados por la consulta transmitidas por el MySQL server (nodo SQL).

Para chequear el rendimiento base de estos métodos de acceso hemos desarrollado un conjunto de benchmarks. Uno de ellos testReadPerf, testea accesos simple y en batch por clave primaria y única. Este benchmark también mide el coste de preparar los escaneos de rango ejecutando escaneos que retornan un único registro. Hay una variante de este benchmark que usa un escaneo de rango para recibir un batch de registros.

De este modo, podemos determinar el coste de accesos de clave única y accesos de escaneo de registro simple, así como medir el impacto del medio de comunicación usdo, en métodos de acceso base.

En nuestros tests, ejecutamos los benchmarks para transporters normales usando sockets TCP/IP sockets y una configuración similar usando sockets SCI. Las figuras posteriores son pequeños accesos de 20 registros por acceso. Las diferencias entre accesos seriales y mediante batch se decrementan en un factor de 3 a 4 usando registros de 2 kB. SCI Sockets no se testearon con registros de 2 kB. Los tests se realizaron en un cluster con 2 nodos de datos en 2 máquinas de CPU dual equipadas con procesadores AMD MP1900+ .

Tipo de acceso:          TCP/IP sockets           SCI Socket
Acceso Serial clave primaria:   400 microsegundos         160 microsegundos
Acceso Batched clave primaria    28 microsegundos          22 microsegundos
Acceso Serial indice unico:     500 microsegundos         250 microsegundos
Acceso Batched indice unico:     70 microsegundos          36 microsegundos
Acceso Indexado igualdad:      1250 microsegundos         750 microsegundos
Índice rango:                    24 microsegundos          12 microsegundos

También realizamos otro conjunto de tests para chequear el rendimiento de los SCI Sockets vis-à-vis contra el SCI transporter, y ambos comparados con el TCP/IP transporter. Todos estos tests usaron acceso por clave primaria de forma serial o multi-flujo, o multi-flujo y batch.

Los tests mostraron que los sockets SCI eran 100% más rápido que TCP/IP. El transporter SCI era más rápido en la mayoría de casos comparado con los sockets SCI. Un caso notable ocurrión con muchos flujos en el programa de test, que mostró que el tramporter SCI no funcionaba muy bien usado por el proceso mysqld.

Nuestra conclusión global fue que, para la mayoría de benchmarks, usando sockets SCI mejoraba el rendimiento aproximadamente 100% sobre TCP/IP, excepto en raros casos cuando el rendimiento de la configuración no es un tema importante. Esto puede ocurrir cuando los filtros de escaneo toman la mayoría del tiempo de proceso o cuando los procesos batchs muy grandes de accesos por clave primaria se realizan. En tal caso, el proceso de la CPU en los procesos ndbd es la mayor parte del proceso.

Usar el transporter SCI en lugar de SCI Sockets sólo es de interés en comunicación entre procesosndbd. Usar el SCI transporter también es sólo de interés si una CPU puede dedicarse al proceso ndbdya que el SCI transporter se asegura que su proceso nunca estará en espera. Es importante asegurar que la prioridad del proceso ndbd está configurada de tal modo que el proceso no pierde prioridad debido a ejecutarse durante un periodo de tiempo extendido, como puede pasar por bloqueo de procesos por la CPU en Linux 2.6. Si tal configuración es posible, entonces el proceso ndbd se beneficiará de un 10-70% comparado con usar SCI sockets. (Las diferencias más grandes se verán al realizar actualizaciones y probablemente en escaneos paralelos también

Hay otras implementaciones de socket para clusters de máquinas, incluyendo Myrinet, Gigabit Ethernet, Infiniband y la interfaz VIA . Hemos testeado MySQL Cluster hasta ahora sólo con SCI sockets.También incluímos documentación acerca de cómo preparar SCI sockets usando TCP/IP ordinario para MySQL Cluster.

16.8. Limitaciones conocidas de MySQL Cluster

En esta sección, proporcionamos un listado de las limitaciones conocidas en versiones de MySQL Cluster en las series 4.1.x comparadas con características disponibles al usar los motores MyISAM e InnoDB. Actualmente, no hay planes para arreglarlas en próximas versiones 4.1; sin embargo, intentaremos proporcionar soluciones para éstas en MySQL 5.0 y versiones posteriores. Si chequea la categoría de Cluster en la base de datos de bug de MySQL en http://bugs.mysql.com, encontrará bugs conocidos que (si están marcados como 4.1) intentaremos arreglar en próximas versiones de MySQL 4.1.

No cumplimiento de la sintaxis (resultando en errores al ejecutar aplicaciones existentes):
- No se soportan todos los conjuntos de caracteres y colaciones.
- No hay índices prefijo; sólo los campos completos pueden indexarse.
- Los índices de texto no están soportados.
- Tipos de datos geométricos (WKT y WKB) no soportados.
No cumplimiento con límites/comportamiento (puede resultar en errores al ejecutar aplicaciones existentes):
- No hay rollback parcial de transacciones. Una clave duplicada o error similar resultará en un rollback de la transacción completa.
- Existen un número de límites de hard que son configurables, pero la memoria disponible en el cluster delimite al límite. Consulte la lista completa de parámetros de configuración en Sección 16.4.4, “Fichero de configuración”. La mayoría de parámetros de configuración pueden actualizarse en línea. Estos límites de hard incluyen:
  - Tamaño de memoria de base de datos y de memoria índice (DataMemory y IndexMemory, respectivamente).
  - El máximo número de transacciones que pueden ejecutarse se delimita mediante el parámetroMaxNoOfConcurrentOperations. Tenga en cuenta que la cantidad de carga , TRUNCATE TABLE, yALTER TABLE se tratan como casos especiales mediante ejecución de transacciones múltiples, y por lo tanto no están sujetas a esta limitación.
  - Los distintos límites relacionados con tablas e índices. Por ejemplo, el número máximo de índices ordenados por tabla lo determina MaxNoOfOrderedIndexes.
- Los nombres de bases de datos, tablas y atributos no pueden ser tan largos en NDB como con otros motores. Los nombres de atributos se truncan a 31 caracteres, y si no son únicos tras truncarse da lugar a error. Los nombres de base de datos y de tabla pueden tener en total un máximo de 122 caracteres. (Esto es, la longitud máxima para un nombre de tabla en un cluster NDB es 122 caracteres menos el número de caracteres en el nombre de la base de datos de la tabla.)
- En MySQL 4.1 y 5.0, todos los registros de tabla de Cluster son de longitud fija. Esto significa (por ejemplo) que si una tabla tiene uno o más campos VARCHAR conteniendo sólo valores pequeños, serán necesarios más memoria y espacio de disco al usar el motor NDB que el que sería para la misma tabla y datos usando el motor MyISAM. Estamos trabajando para rectificar este punto en MySQL 5.1.
- El máximo número de objetos de metadatos está limitado a 1600, incluyendo tablas de base de datos, tablas de sistema, índices y BLOBs. Estamos trabajando para incrementar esto a aproximadamente 20k en MySQL 5.0.
- El máximo número de atributos por tabla está limitado a 128.
- El tamaño máximo permitido de registro es 8k, sin incluir datos almacenados en columnas BLOB. Esperamos incrementar esto a aproximadamente 32k en MySQL 5.1.
- El máximo número de atributos por clave es 32.
Características no soportadas (no causan errores, pero no están soportadas o forzadas):
- El constructor de clave primaria se ignora, como en tablas MyISAM .
- Los puntos de chequeo y rollbacks se ignoran como en MyISAM.
Rendimiento y temas relacionados con limitaciones :
- La caché de consulta está desactivada, ya que no está invalidad si ocurre una actualización en distintos servidores MySQL.
- Hay temas de rendimiento de consulta debido a acceso secuencial al motor NDB; también es relativamente más costoso hacer varios escaneos de rango que con MyISAM o InnoDB.
- La estadística Records in range no está soportada, resultando en planes de consulta no óptimos en algunos casos. Use USE INDEX o FORCE INDEX como solución.
- Índices hash únicos creados con USING HASH no pueden usarse para acceder a una tabla si NULL se da como parte de la clave.
Caracterísitcas no incluídas:
- El único nivel de isolación soportado es READ_COMMITTED. (InnoDB soporta READ_COMMITTED,REPEATABLE_READ, y SERIALIZABLE.) Consulte Sección 16.6.4.5, “Resolver problemas con copias de seguridad” para información sobre cómo puede afectar a las copias de seguridad y restauración de bases de datos Cluster.
- Commits no durables en disco. Los commits se replican, pero no hay garantía que los logs se vuelquen a disco en un commit.
Problemas relacionados con múltiples MySQL servers (no relacionados con MyISAM o InnoDB):
- ALTER TABLE no es completamente bloqueante cuando se ejecutan múltiples MySQL servers (no hay bloqueo de tabla distribuído).
- La replicación MySQL no funcionará correctamente si las acutalizaciones se hacen en múltiples MySQL servers. Sin embargo, si el esquema de particionado de la base de datos es en nivel de aplicación, y no hay transacciones entre estas particiones, la replicación puede funcionar.
- El autodescubrimiento de bases de datos no se soporta para múltiples MySQL servers accediendo al mismo MySQL Cluster. Sin embargo, el autodescubrimiento de tablas se soporta en estos casos. Lo que significa que si tras una base de datos llamada db_name se crea o importa usando un MySQL server, debe ejecutar un CREATE DATABASE db_name; en cada MySQL server adicional que accede al mismo MySQL Cluster. (Desde MySQL 5.0.2 puede usar CREATE SCHEMA db_name;.) Una vez hecho esto para un MySQL server dado, el servidor debería ser capaz de detectar las tablas de la base de datos sin error.
Temas exclusivos de MySQL Cluster (no relacionados con MyISAM o InnoDB):
- Todas las máquinsa usadas en el cluster deben tener la misma arquitectura; esto es, todas las máquinas con nodos deben ser o big-endian o little-endian, y no puede usar una mezcla. Por ejemplo, no puede tener un nodo de administración ejecutándose en un PPC con un nodo datos en una máquina x86 . Esta restricción no se aplica a máquinas que ejecuten sólo mysql u otros clientes que puedan estar accediendo a los nodos SQL del cluster.
- No es posible hacer cambios del esquema en línea tales como los realizados usando ALTER TABLE oCREATE INDEX, ya que NDB Cluster no soporta autodescubrimiento de tales cambios. (Sin embargo, puede importar o crear una tabla que use distintos motores, convertirlos a NDB usando ALTER TABLEtbl_name ENGINE=NDBCLUSTER;. En tales casos, necesitará ejecutar un comando FLUSH TABLESpara forzar al cluster a recoger los cambios.)
- Añadir o eliminar nodos en línea no es posible (el cluster debe reiniciarse en tales casos).
- Cuando se usan múltiples servidores de administración debe dar a los nodos explícitamente los IDs en los connectstrings ya que la reserva automática de IDs de nodo no funciona entre múltiples servidores de administración.
- Usando varios servidores de administración debe tener cuidado de tener la misma configuración para todos los servidores de administración. El cluster no hace chequeos para ello.
- El número máximo de nodos de datos es 48.
- El número máximo de nodos en MySQL Cluster es 63. Este número incluye todos los MySQL Servers (nodos SQL), nodos de datos, y servidores de administración.

Este listado trata de ser completo respecto al conjunto de condiciones del principio de esta sección. Puede reportar cualquier discrepancia que encuentre a la base de datos de bugs de MySQL en http://bugs.mysql.com/. Si no planeamos arreglar el problema n MySQL 4.1, lo añadiremos a la lista anterior.

16.9. Mapa de desarrollo de MySQL Cluster

16.9.1. Cambios de MySQL Cluster en MySQL 5.0
16.9.2. Mapa de desarrollo de MySQL 5.1 para MySQL Cluster

En esta sección, discutimos los cambios en la implementación de MySQL Cluster en MySQL 5.0 comparadas con MySQL 4.1. También discutiremos nuestra planificación para futuras mejoras en MySQL Cluster planeadas para MySQL 5.1.

En el pasado hemos recomendado que los usuarios de MySQL Cluster no usen la versión 5.0 de MySQL ya que MySQL Cluster en las series 5.0.x no estaba completamente testeada. A partir de MySQL 5.0.3-beta la funcionalidad de clustering de MySQL 5.0 es comparable a la de MySQL 4.1. MySQL 4.1 es la recomendada para producción por ahora; sin embargo, MySQL 5.0 es de alta calidad también, y le animamos a testear Cluster en MySQL 5.0 si piensa que está interesado en usarla cuando enter en producción a finales de 2005. Hay pocos cambios entre implementaciones NDB Cluster en MySQL 4.1 y en 5.0, así que la actualización es relativamente sencilla y rápida.

Desde que MySQL 5.0.3-beta está disponible, casi todas las nuevas características significativas desarrolladas para MySQL Cluster van al árbol de MySQL 5.1 . Proporcionamos algunas pistas acerca de lo que Cluster en MySQL 5.1 incluirá en el final de esta sección (consulte Sección 16.9.2, “Mapa de desarrollo de MySQL 5.1 para MySQL Cluster”).

16.9.1. Cambios de MySQL Cluster en MySQL 5.0

MySQL 5.0.3-beta y posterior contiene un número de nuevas características que son de interés:

Condiciones Push-Down: Una consulta como
```
SELECT * FROM t1 WHERE non_indexed_attribute = 1;
```
usará un escaneo de toda la tabla y la condición se evaluará en los nodos de datos del cluster. Por lo tanto no es necesario enviar el registro a la red para evaluación. (Esto es, la transporte de función se usa, en lugar del transporte de datos.) Para este tipo de consultas debe observar un factor de incremento de velocidad de 5-10. Tenga en cuenta que esta característica actualmente está desactivada por defecto (pendiente de más testeo), pero debería funcionar en la mayoría de casos. Esta característica puede estar activada mediante el comando SET engine-condition-pushdown=On; . Alternativamente, puede ejecutar mysqld con esta característica activada arrancando MySQL server con la nueva opción --engine-condition-pushdown.

Puede usar EXPLAIN para determinar cuándo se usan las condiciones push-down .

Un beneficio principal de este cambio es que las consultas se ejecutan en paralelo. Esto significa que las consultas contra columnas no indexadas pueden mejorar de 5 a 10 veces, veces por el número de nodos de datos, más rápido que préviamente, ya que CPUs múltiples pueden funcionar en la consulta en paralelo.
Decrementado uso de IndexMemory: En MySQL 5.0, cada registro consume aproximadamente 25 bytes de memoria índice, y cada índice único usa 25 bytes por registro de memoria índice (además de alguna memoria de datos ya que se almacena en una tabla separada). Esto es porque no hay almacenamiento de la clave primaria en la memoria índice.
Caché de consulta activada para MySQL Cluster: Consulte Sección 5.12, “La caché de consultas de MySQL” para información acerca de configurar el uso de la caché de consulta.
Nuevas optimizaciones: Una optimización que merece atención particular es que una interfaz de lectura batch se usa ahora en algunas consultas. Por ejemplo, considere la siguiente consulta:
```
SELECT * FROM t1 WHERE primary_key IN (1,2,3,4,5,6,7,8,9,10);
```
Esta consulta se ejecutará 2 o 3 veces más rápido que en versiones anteriores de MySQL Cluster debido al hecho que todas las 10 búsquedas de clave se envían en un batch único en lugar de uno cada vez.
Límite en número de objetos de metadatos : En MySQL 4.1, cada base de datos de Cluster puede contener un máximo de 1600 objetos de metadatos, incluyendo tablas de base de datos, tablas de sistema, índices y BLOBs. En MySQL 5.0, esperamos incrementar este número a 20,320. Esperamos implementar esta mejora en MySQL 5.0.6 beta a mediados de 2005.

16.9.2. Mapa de desarrollo de MySQL 5.1 para MySQL Cluster

Aquí se habla de un reporte de estado basado en recientes commits en el árbol fuente MySQL 5.1 . Debería tenerse en cuenta que todo el desarrollo 5.1 está sujeto a cambio.

Actualmente hay 4 nuevas funcionalidades mayores en desarrollo para MySQL 5.1:

Integración de MySQL Cluster con MySQL Replication: Esto hará posible actualizar desde cualquier MySQL Server en el cluster y tener MySQL Replication tratada por uno de los MySQL Servers en el cluster y la instalación de un esclavo consistente.
Soporte para registros basados en disco: Los registros en disco se soportarán. Los campos índice incluyendo el índice hash de clave primaria debe almacenarse en RAM pero todos los otros campos pueden estar en disco.
Registros de tamaño variable: Una columna definida como VARCHAR(255) actualmente usa 260 bytes de almacenamiento independiente de lo que se almacena en un registro particular. En tablas MySQL 5.1 Cluster sólo la porción del campo tomada por el registro se almacena. Esto hará posible una reducción de los requerimientos de espacio para tales columnas por un factor de 5 en muchos casos.
Partición definida por el usuario: Los usuarios serán capaces de definir particiones basadas en las partes de los campos de la clave primaria. El MySQL Server será capaz de descubrir si es posible de eliminar algunas de las particiones de la cláusula WHERE . La partición basada en KEY, HASH, RANGE, yLIST será posible, así como subparticiones. Esta característica debe estar disponible para otros criterios.

Además, estamos trabajando para incrementar el límite de tamaño de 8k para los registros que contienen columnas de tipos distintos a BLOB o TEXT en tablas cluster. Esto es debido al hecho que los registros están fijados en tamaño y el tamaño de página es de 32,768 bytes (menos 128 bytes para la cabecera del registro.) Esto significa actualmente que si permitimos más de 8k por registro, cualquier espacio que quede (hasta aproximandamente 14,000 bytes) quedaría vacío. En MySQL 5.1, planeamos para arreglar esta limitación para que use más de 8k en un registro dado no resulta en que se gaste lo que queda de la página.

16.10. Preguntas frecuentes sobre MySQL Cluster

¿Qué diferencia hay entre usar cluster y replicación?

En una replicación, un servidor maestro MySQL actualiza uno o más esclavos. Las transacciones hacen commit secuencialmente, y una transacción lenta puede causar que el esclavo quede desactualizado. Esto significa que si falla el maestro, es posible que el esclavo pueda no haber registrado las últimas transacciones. Si un motor transaccional como InnoDB se usa, una transacción será completa en el esclavo o no aplicada en absoluto, pero la replicación no garantiza que todos los datos en el maestro y el esclavo sean consistentes siempre. En MySQL Cluster,todos los nodos de datos con un commit hecho por algun nodo de datos se realiza un commit para todos los nodos. En caso de un fallo de un nodo de datos, todos los nodos de datos restantes quedarán en un estado consistente.

En breve, mientras que la replicación estándar MySQL es asíncrona, MySQL Cluster es síncrono.

Planeamos implementar replicación asíncrona para Cluster en MySQL 5.1. Esto incluye la capacidad de replicar entre dos cluster y entre un cluster MySQL y un MySQL server no cluster.
¿Necesito hacer alguna configuración especial de red para el Cluster? (¿Cómo se comunican las máquinas en un cluster?)

MySQL Cluster está pensado para usarse en un entorno de gran ancho de banda, con máquinas conectadas via TCP/IP. Su rendimiento depende directamente en la velocidad de conexión entre las máquinas del cluster. Los requerimientos de conectividad mínimo para cluster incluyen una red típica 100-megabit Ethernet o equivalente. Recomendamos usar Ethernet cuando sea posible.

También se soporta el protocolo SCI (más rápido), pero necesita hardware especial. ConsulteSección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más información acerca de SCI.
¿Cuántas máquinas necesito para ejecutar un cluster, y porqué?

Como mínimo se necesitan tres máquinas. Sin embargo, el número mínimo recomendado en MySQL Cluster es cuatro: una para el nodo de administración y otra para el de SQL, y dos para servir como nodos de almacenamiento. El propósito de los dos nodos de datos es proporcionar redundancia; el nodo de administración debe ejecutarse en una máquina separada para garantizar servicio de arbitración contínuo en caso que un nodo de datos falle.
¿Qué hacen las distintas máquinas en un cluster?

Un MySQL Cluster tiene organización física y lógica, con máquinas como elementos físicos. Los elementos lógicos son los nodos, y una máquina hospedando un nodo es un huesped cluster. Idealmente, habrá un nodo por huesped cluster, aunque es posible ejecutar más de un nodo en una máquina. Hay tres tipos de nodos, cada uno correspondiente a un rol específico en el cluster. Son:
1. nodo de administración (nodo MGM) : Proporciona servicios de administración para todo el cluster, incluyendo arranque, parada, copias de seguridad, y datos de configuración en otros nodos. El nodo de administración se implementa como la aplicación ndb_mgmd; el cliente de administración usado para controlar MySQL Cluster via nodo MGM es ndb_mgm.
2. nodo de datos: Almacena y replica datos. La funcionalidad de los nodos de datos la trata una instancia del proceso NDB ndbd.
3. nodo SQL: Símplemente es una instancia de MySQL Server (mysqld) arrancado con la opción --ndb-cluster.
¿Qué sistemas operativos pueden usar Cluster?

En MySQL 5.0, MySQL Cluster se soporta oficialmente en Linux, Mac OS X, y Solaris. Estamos trabajando para añadir soporte a cluster para otras plataformas, incluyendo Windows, y nuestra finalidad es eventualmente ofrecer MySQL Cluster en todas las plataformas en que se soporta MySQL .

Puede ser posible ejecutar procesos Cluster en otros sistemas operativos. Hemos tenido reportes de usuarios que dicen que han ejecutado Cluster en FreeBSD. Sin embargo, Cluster en cualquier plataforma que no sen las 3 mencionadas aquí se considera software alfa (como mucho), no puede garantizarse el buen funcionamiento en un entorno de producción, y no lo soporta MySQL AB.
¿Cuáles son los requerimientos de hardware para ejecutar MySQL Cluster?

Cluster debe ejecutarse en cualquier plataforma en que los binarios de NDB estén disponibles. Naturalmente, una CPU más rápida y más memoria mejora el rendimiento, y CPUs de 64 bits serán mejores que los procesadores de 32. Debe haber suficiente memoria en las máquinas usadas por los nodos de datos para tratar cada parte de la base de datos (consulte ¿Cuánta RAM necesito? para más información). Los nodos pueden comunicarse via TCP/IP estándard y su hardware. Para soporte SCI, se necesita hardware especial de red.
Como MySQL Cluster usa TCP/IP, ¿significa que puedo usarlo en Internet, con uno o más nodos en una localización remota?

Es importante tener presente que la comunicación entre nodos en MySQL Cluster no es segura ; no está encriptada ni guardada por ningún otro mecanismo. La configuración más segura para un cluster es en una red privada detrás de un firewall, sin acceso directo a ningún nodo de datos ni de administración desde fuera.

Es muy dudoso que un cluster se muestre fiable bajo tales condiciones, ya que se diseñó e implementó con la suposición que se ejecutaría bajo condiciones que garantizaran conectividad dedicada de alta velocidad como las encontradas en configuraciones en una LAN con 100 Mbps o gigabit Ethernet (mejor la última). No testeamos ni garantizamos el rendimiento usando algo más lento que esto.
¿Debo usar nuevos lenguajes de programación o de consulta para usar Cluster?

No. Aunque se usan algunos comandos especializados para administrar y configurar el cluster, solo comandos estándard (My)SQL se necesitan para:
- Crear, alterar y borrar tablas
- Insertar, actualizar y borrar datos de tabla
- Crear, cambiar y borrar índices únicos y primarios
- Configurar y administrar nodos SQL (servidores MySQL)
¿Cómo puedo sabar qúe significan loa mensajes de error o advertencias al usar Cluster?

Se puede hacer de dos modos:
1. Desde el MySQL Monitor, use SHOW ERRORS o SHOW WARNINGS inmediatamente al recibir la notificación del error o advertencia. También se pueden mostrar en MySQL Query Browser.
2. De un shell de sistema, use perror --ndb error_code.
¿Es MySQL Cluster transaccional? ¿Qué tipo de tablas se soportan en Cluster ?

Sí. MySQL Cluster utiliza tablas creadas con el motor NDB , que soporta transacciones. NDB es el único motor que soporta cluster.
¿Qué significa “NDB”?

Significa "Network Database".
¿Qué versiones de MySQL software soportan Cluster? ¿Debo compilarlo de las fuentes?

Cluster se soporta en todos los binarios MySQL-max en la serie 5.0, excepto lo que se explica en el siguiente parágrafo. Puede determinar si su servidor soporta o no NDB usando los comandos SHOW VARIABLES LIKE 'have_%'; o SHOW ENGINES;. (Consulte Sección 5.1.2, “El servidor extendido de MySQL mysqld-max” para más información.)

Usuarios de Linux , tengan en cuenta que NDB no se incluye en los RPM estándar de MySQL server. Desde MySQL 5.0.4, hay paquetes RPM separados para el motor NDB junto con herramientas de administración; consulte la sección de descargas NDB RPM de MySQL 5.0 Downloads . (Antes de 5.0.4, debe usar los binarios -max proporcionados como .tar.gz . Todabía es posible, pero no es un requerimiento, así que puede usar su administración de RPMs de Linux si lo prefiere.) Puede obtener soporte NDB compilando los binarios -max de las fuentes, pero no es necesario hacerlo para usar MySQL Cluster. Para descargar los últimos binarios, RMP o distribución fuente en la serie MySQL 5.0 visite http://dev.mysql.com/downloads/mysql/5.0.html.
¿Cuánta RAM necesito? ¿Es posible usar memoria de disco?

Actualmente, Cluster sólo funciona en memoria. Esto significa que todos los datos de tabla (incluyendo índices) se almacena en RAM. Por lo tanto, si sus datos ocupan 1 GB de espacio y quiere replicarlo en el cluster, necesitará 2 GB de memoria para ello. Esto es a parte de la memoria necesaria para el sistema operativo y cualquier aplicación ejecutándose en las máquinas del cluster.

Puede usar la siguiente fórmula para obtener una estimación aproximada de cuánta RAM necesita para cada nodo de datos en el cluster:
```
(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes
```
Para calcular los requerimientos de memoria con más exactitud debe determinar, para cada tabla en la base de datos del cluster, el espacio de almacenamiento requerido por registro (consulte Sección 11.5, “Requisitos de almacenamiento según el tipo de columna” para más detalles), y multiplicarlo por el número de registros. Debe recordar tener en cuenta cualquier índice de columna como sigue:
- Cada clave primaria o índice hash creado para una tabla NDBCluster necesita 21-25 bytes por registro. Estos índices usan IndexMemory.
- Cada índice ordenado necesita 10 bytes de almacenamiento por registro, usando DataMemory.
- Crear una clave primaria o índice único también crea un índice ordenado, a no ser que este índice se cree con USING HASH. En otras palabras, si se crea sin USING HASH, una clave primaria o índice único en una tabla Cluster ocupará hasta 31-35 bytes por registro en MySQL 5.0.
  
  Tenga en cuenta que crear tablas MySQL Cluster con USING HASH para todas las claves primarias e índices únicos generalmente causará que las actualizaciones de tablas sean más rápidas. Esto es debido al hecho que se necesita menos memoria (ya que no se crean índices únicos), y que debe usarse menos CPU (ya que se deben leer y actualizar menos índices).
Es especialmente importante tener en mente que cada tabla en MySQL Cluster debe tener clave primaria, que el motor NDB creará una clave primaria automáticamente si no se define y que esta clave primaria se crea sin USING HASH.

No hay una forma sencilla en MySQL 5.0 para determinar exactamente cuánta memoria se está usando para almacenar índices Cluster en un momento dado; sin embargo, las advertencias se escriben en el log del cluster cuando el 80% de memoria DataMemory y/o IndexMemory está en uso, y de nuevo al 85%, 90% etc.

A menudo vemos preguntas de usuarios que reportan que, cuando intentan rellenar una base de datos cluster, el proceso de carga termina prematuramente y aparece un mensaje de error como este:
```
ERROR 1114: The table 'my_cluster_table' is full
```
Cuando esto ocurre, la causa es que su configuración no proporciona suficiente RAM para todos los datos de tablas e índice , incluyendo la clave primaria requerida por el motor NDB y creada automáticamente en el caso que la definición de tabla no incluya la definición de la clave primaria.

Vale la pena tener en cuenta que todos los nodos de datos deben tener la misma cantidad de RAM, ya que ningún nodo de datos en el cluster puede usar más memoria que la mínima cantidad disponible para cualquier nodo de datos individual. En otras palabras, si hay tres máquinas con nodos de datos y dos tienen 3 GB RAM disponibles y otro sólo 1 GB de RAM, entonces cada nodo sólo puede usar 1 GB para el cluster.
En caso de un fallo catastrófico — por ejemplo, que la ciudad entera se queda sin electricidad y mi UPS falla — ¿perdería todos mis datos?

Todas las transacciones con commit se loguean. Por lo tanto, aunque es posible perder algunos datos en caso de catástrofe, debería ser algo limitado. La pérdida de datos puede reducirse minimizando el número de operaciones por transacción. (No es buena idea realizar un gran número de operaciones por transacción en cualquier caso.)
¿Es posile usar índices FULLTEXT con Cluster?

La indexación FULLTEXT no se soporta en el motor NDB , o por cualquier motor que no sea MyISAM. Estamos trabajando para añadir esta funcionalidad en nuevas versiones.
¿Puedo ejectura múltiples nodos en una sola máquina?

Es posible pero no recomendable. Una de las razones principales para ejecutar un cluster es proporcionar redundancia; para tener todos los beneficios de esta redundancia, cada nodo debe residir en máquinas separadas. Si tiene múltiples nodos en una misma máquina y esta falla, pierde todos estos nodos. Dado que MySQL Cluster puede ejecutarse en hardware dedicado cargado con sistemas operativos de bajo o ningún coste, vale la pena el gasto en una o dos máquina extra para guardar datos críticos. También vale la pena tener en cuenta que los requerimientos para una máquina cluster ejectuando un nodo de administración son mínimos; esta tarea puede realizarse con una CPU 200 MHz Pentium y suficiente RAM para el sistema operativo más una mínima cantidad de sobrecarga para los procesos ndb_mgmd y ndb_mgm .
¿Puedo añadir nodos en un cluster sin reiniciarlo?

No. Un reinicio es necesario para añadir nuevos nodos MGM o SQL. Al añadir nodos de datos el proceso es más complejo, y necesita los siguientes pasos:
- Hacer una copia de seguridad completa de todos los datos del cluster.
- Parar todo el cluster y procesos de los nodos.
- Reiniciar el cluster, usando la opción --initial
- Restaurar todos los datos desde la copia de seguridad
En el futuro, esperamos implementar capacidad de reconfiguración “hot” para MySQL Cluster para minimizar (o eliminar) los requerimientos para reiniciar el cluster al añadir nuevos nodos.
¿Hay alguna limitación que deba tener en cuenta al usar Cluster?

Las tablas NDB tienen las siguientes limitaciones:
- No se soportan todos los conjuntos de caracteres y colaciones.
- Índices FULLTEXT y prefijo no están soportados. Sólo pueden indexarse columnas completas.
- Capítulo 18, Extensiones espaciales de MySQL no se soportan.
- Sólo se soporta rollback completo para transacciones. Los rollback parciales y rollbacks en checkpoints no se soportan.
- El máximo número de atributos permitidos por tabla es 128, y los nombres de atributo no pueden tener más de 31 caracteres. Para cada tabla, la longitud máxima combinada del nombre de tabla y de base de datos es 122 caracteres.
- El tamaño máximo para un registro de tabla es de 8 kilobytes, sin contar BLOBs. No hay límite para el número de registros por tabla; los límites de tamaño de tabla dependen en un número de factores, en particular la cantidad de RAM disponible para cada nodo de datos.
- El motor NDB no soporta claves foráneas. Como con tablas MyISAM, se ignoran.
- No se soporta el caché de consulta.
Para información adicional de limitaciones de cluster, consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster”.
¿Cómo importo una base de datos existente en un cluster?

Puede importar bases de datos en MySQL Cluster como con cualquier otra versión de MySQL. A parte de las limitaciones mencionadas anteriormente, el único requerimiento especial es que cualquier tabla que se incluya en el cluster debe usar el motor NDB. Esto significa que las tablas deben crearse con la opción ENGINE=NDB o ENGINE=NDBCLUSTER.
¿Cómo se comunican los nodos del cluster entre ellos?

Los nodos del Cluster pueden comunicarse meiante tres protocolos: TCP/IP, SHM (memoria compartida), y SCI (Scalable Coherent Interface). Donde está disponible, SHM se usa por defecto entre nodos residentes en el mismo equipo de cluster. SCI es un protocolo de alta velocidad (1 gigabit por segundo o más), alta disponibilidad usado en construir sistemas escalables de multi procesador; requiere hardware especial y drivers. Consulte Sección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más información usando SCI como mecanismo de transporte en MySQL Cluster.
¿Qué es un “árbitro”?

Si uno o más nodos en un cluster fallan, es posible que no todos los nodos del cluster será capaz de “verse” entre ellos. De hecho, es posible que dos conjuntos de nodos puedan a estar aislados de los otros en una partición de red, también conocido como un escenario “split brain”. Este tipo de situación no es deseable ya que cada conjunto de nodos trata de comportarse como si fuera el cluster entero.

Cuando caen los nodos del cluster, hay dos posibilidades. Si más del 50% de los nodos restantes pueden comunicarse entre ellos, entonces tenemos lo que a veces se llama “reglas de mayoría” , y este conjunto de nodos se consideran como el cluster. El árbitro entra en juego cuando hay un número impar de nodos: en tales casos, el conjunto de nodos al que pertenece el árbitro se considera el cluster, y los nodos que no pertenecen a este grupo se paran.

La información anterior está simplificada; a continuación hay una explicación más completa:

Cuando todos los nodos en al menos un grupo de nodos está vivo, la partición de la red no es un problema, porque ninguna porción del cluster puede formar un cluster funcional. El problem real es cuando un grupo no tiene todos sus nodos vivos, en tal caso la partición de red (el escenario “split-brain” mencinado anteriormente) es posible. Cuando se necesita un árbitro, que normalmente es el servidor de administración; sin embargo, es posible configurar cualquier MySQL Server en el cluster para que actúe como el árbitro. El árbitro acepta el primer conjunto de nodos del cluster que contacten con el, y le dice al resto que mueran. La selección del árbitro se controla mediante el parámetro de configuraciónArbitrationRank para los nodos MySQL Server y de administración. (Consulte Sección 16.4.4.4, “Definición del servidor de administración de MySQL Cluster” para más detalles.) Debe tener en cuenta que el rol de administrador no impone ninguna demanda en la máquina designada, y por lo tanto la máquina árbitro no necesita ser particularmente rápida o tener memoria extra para este propósito.
¿Qué tipos de columna soport MySQL Cluster?

MySQL Cluster soporta todos los tipos de columna MySQL usuales, con la excepción de los asocidados con las extensiones espaciales. (Consulte Capítulo 18, Extensiones espaciales de MySQL.) Además, hay algunas diferencias respecto a los índices cuando se usan con tablas NDB. Nota: En MySQL 5.0, las tablas Cluster (esto es, tablas creadas con ENGINE=NDBCLUSTER) tiene sólo registros de longitud fija. Esto significa que (por ejemplo, cada registro conteniendo una columna VARCHAR(255) necesitará 256 bytes de almacenamiento para esa columna, independientemente del tamaño de los datos almacenados. Este punto se arreglará en futuras versiones.

Consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster” para más información.
¿Cómo arranco y paro MySQL Cluster?

Es necesario arrancar cada nodo en el cluster por separado en el siguiente orden:
1. Arranque el nodo de administración con el comando ndb_mgmd .
2. Arranque cada nodo de datos con el comando ndbd.
3. Arranque cada servidor MySQL (nodo SQL) usando mysqld_safe --user=mysql &.
Cada uno de estos comandos debe ejecutarse en una shell de sistema en la máquina que contenga el nodo afectado. Puede verificar que el cluster está en ejecución arrancando el cliente de administración MGM . ndb_mgm en la máquina con el nodo MGM.
¿Qué ocurre a los datos del cluster cuando el cluster se para?

Los datos en memoria de los nodos de datos se escriben en disco, y se recargan en memoria la siguiente vez que se inicia el cluster.

Para parar el cluster, introduzca lo siguiente en una shell en la máquina del nodo MGM:
```
shell> ndb_mgm -e shutdown
```
Esto hace que ndb_mgm, ndb_mgm, y cualquier proceso ndbd termina correctamente. MySQL servers corriendo como nodos Cluster SQL pueden pararse usando mysqladmin shutdown.

Para más información, consulte Sección 16.6.1, “Comandos del cliente de administración” ySección 16.3.6, “Apagado y encendido seguros”.
¿Es útil tener más de un nodo de administración para el cluster?

Puede ser útil para ser más seguro. Sólo un nodo MGM controla el cluster en un momento dado, pero es posible configurar un MGM como primario, y otro o más nodos adicionales para tomar el control en caso de fallo del nodo MGM primario.
¿Puedo mezclar hardware y sistemas operativos distintos en un Cluster?

Sí, mientras todas las máquinas y sistemas operativos tengan la misma endian. Es posible usar distintas versiones de MySQL Cluster en nodos distintos; sin embargo, recomendamos que esto se haga sólo como parte del procedimiento de actualización.
¿Puedo ejecutar dos nodos de datos en una misma máquina? ¿Dos nodos SQL?

Sí. En el caso de múltiples nodos de datos, cada nodo debe usar un directorio de datos distinto. Si quiere ejectuar múltiples nodos SQL en una máquina, entonces cada instancia de mysqld debe usar un puerto TCP/IP distinto.
¿Puedo usar nombres de equipo con MySQL Cluster?

Sí, es posible usar DNS y DHCP para equipos del cluster. Sin embargo, si su aplicación necesita disponibilidad de "cinco nueves", recomendamos usar direcciones IP fijas. Esto es porque hacer la comunicación entre equipos del cluster dependiente de estos servicios introduce puntos de fallo adicionales, y mientras menos haya, mejor.

16.11. Glosario de MySQL Cluster

Los siguientes términos son útiles para enteneder MySQL Cluster o tienen significado eespecial cuando se usan referidos a ellos.

Cluster:

En sentido genérico, un cluster es un conjunto de máquinas funcionando como unidad y trabajando juntas para tratar una única tarea.

NDB Cluster:

Este es el motor de almacenamiento usado en MySQL para implementar almacenamiento de datos, recuperación y administración distribuída entre varias máquinas.

MySQL Cluster:

Se refiere a un grupo de máquinas trabajando juntas usando el motor NDB para soportar una base de datos MySQL distribuída en una arquitectura de compartición nula usando almacenamiento en memoria.
Ficheros de configuración:

Ficheros de texto conteniendo directivas e información respecto al cluster, sus máquinas y sus nodos. Son leídos por los nodos de administración de cluster y cuando arranca el cluster. ConsulteSección 16.4.4, “Fichero de configuración” para detalles.
Copia de seguridad:

Una copia completa de todos los datos de cluster, transacciones y logs, guardados en disco y otro medio de almacenamiento.
Restauración:

Retornar el cluster a un prévio estado, como se almacenó en la copia de seguridad.
Checkpoint:

Generalmente hablando, cuando los datos se guardan en disco, se dice que se llega a un checkpoint. Más específicamente para el cluster, es un punto en tiempo donde todas las transacciones que han hecho un commit se guardan en disco. Respecto al motor NDB, hay dos clases de checkpoints que trabajan juntas para asegurar que se mantiene una vista consistente del cluster:
- Local Checkpoint (LCP):
  
  Este es un checkpoint específico a un nodo; sin embargo LCP se realizan para todos los nodos de forma más o menos concurrentes en todo el cluster. Un LCP inplica guardar todos los datos de los nodos en disco, y esto ocurre normalmente cada pocos minutos. El intervalo preciso varía, y depende de la cantidad de datos almacenada por el nodo, el nivel de la actividad del cluster y otros factores.
- Global Checkpoint (GCP):
  
  Un GCP se realiza cada pocos segundos, cuando las transacciones para todos los nodos se sincronizan y el log de redo se vuelca en disco.
Equipo Cluster:

Una máquina que forma parte del MySQL Cluster. Un cluster tiene una estructura física y una lógica . Físicamente, el cluster consiste en un número de máquinas , conocidas como equipos del cluster (o más símplemente equipos . Consulte Nodo y Grupo de Nodos a continuación.
Nodo:

Se refiere a un unidad lógica o funcional de MySQL Cluster, y a veces se denomina como nodo de cluster . En el contexto de MySQl Cluster, usamos el término “nodo” para indicar un proceso en lugar de un componente físico del cluster. Hay tres tipos de nodo requeridos para implementar un MySQL Cluster. Son:
- Nodos de administración (MGM):
  
  Administra los otros nodos dentro del MySQL Cluster. Proporciona datos de configuración de los otros nodos; arranca y para nodos; trata partición de red; crea copias de seguridad y restaura desde las mismas, y así.
- Nodos SQL (MySQL server):
  
  Instancias de MySQL Server que sirve como front end para cuardar datos en los nodos de datos del cluster. Clientes que quieran almacenan, recuperar o actualizar datos pueden acceder a un nodo SQL sólo como si fuera cualquier otro MySQL Server, empleando los métodos de autenticación usual y API; la distribución subyacente de datos entre grupos de nodos es transparente a los usuarios y aplicaciones. Los nodos SQL acceden a las bases de datos del cluster como un total sin tener en cuenta la distribución de datos entre distintos nodos de datos o máquinas del cluster.
- Nodos de datos:
  
  Estos nodos almacenan los datos. Los fragmentos de datos se almacenan en un conjunto de grupos de nodos. Cada uno de los nodos creando un grupo de nodos almacena una réplica del fragmento para el que ese grupo de nodos es responsable. Actualmente un único cluster puede soportar hasta 48 nodos de datos en total.
Es posible que más de un nodo coexista en una única máquina. (De hecho, es posible tener un cluster completo en una única máquina, aunque no es recomendable hacerlo en un entorno de producción.) Puede ser útil recordar que, cuando se trabaja con MySQL Cluster, el término máquina se refiere a un componente físico del cluster mientras que nodo es un componente lógico o funcional. (un proceso).

Nota respecto a términos obsoletos: En versiones más antiguas de la documentación de MySQL Cluster , los nodos de datos se llaman a veces "nodos de bases de datos" o "nodos DB". Además, los nodos SQL a veces se conocen como "nodos cliente" o "nodos API". Esta terminología antigua ha quedado obsoleta para minimizar confusión, y por estas razones debería evitarse.
Grupo de nodos:

Conjunto de nodos de datos. Todos los nodos de datos en un grupo de nodos contienen los mismos datos (fragmentos), y todos los nodos en un mismo grupo deben estar en distintas máquinas. Es posible controlar qué nodos pertenecen a qué grupos de nodos.
Fallo de nodo:

MySQL Cluster no sólo depende de la funcionalidad de un único nodo en el cluster; el cluster puede continuar funcionando si uno o más nodos fallan. El número preciso de fallos de nodo que puede tolerar un único cluster depende en el número de nodos de la configuración del cluster.
Reinicio de nodo:

El proceso de restaurar un nodo de cluster fallido.
Reinicio de nodo inicial:

El proceso de arrancar un nodo de cluster con su sistema de fichero eliminado. Esto a veces se usa en actualizaciones de software y en otras circunstancias especiales.
Fallo de sistema:

Puede ocurrir cuando han fallado tantos nodos que el estado del cluster no puede garantizarse.
Reinicio de sistema:

El proceso de reiniciar el cluster y reinicializar su estado de logs de disco y checkpoints. Se requiere tras una parada planficada o no del cluster.
Fragmento:

Una porción de una tabla; en el motor NDB una tabla se divide y almacena como un número de fragmentos. Un fragmento es a veces llamado “partición”; sin embargo, “fragmento” es la denominación preferida.Las tablas fragmentadas en MySQL Cluster se usan para facilitar balanceo de carga entre máquinas y nodos.
Réplica:

Bajo el motor NDB , cada fragmento de tabla tiene un número de réplicas almacenadas en otros nodos de datos para proporcionar redundancia. Hay actualmente 4 réplicas por fragmento.
Transporter:

Protocolo que proporciona transferencia de datos entre nodos. MySQL Cluster soporta 4 tipos distintos de conexiones de transporters:
- TCP/IP (local)
  
  Protocolo de red habitual que existe bajo HTTP, FTP (y así ) en Internet.
- TCP/IP (remoto)
  
  Lo mismo que el anterior, excepto que se usa para comunicación remota.
- SCI
  
  Scalable Coherent Interface es un protocolo de alta velocidad usado para montar sistemas multiprocesador y aplicaciones paralelas. El uso de SCI con MySQL Cluster requiere hardware especializado y se discute en Sección 16.7.1, “Configurar MySQL Cluster para que utilice Sockets SCI”. Para una introducción básica a SCI, consulte este ensayo de dolphinics.com.
- SHM
  
  shared memory segments (segmentos de memoria compartida). Donde se soporta, SHM se usa automáticamente para conectar nodos en la misma máquina. La página de man Unix para shmop(2) es un buen sitio para obtener información adicional acerca de este tema.
Nota: El transporter del cluster es interno. Las aplicaciones que usan MySQL Cluster se comunican con nodos SQL como se hace con cualquier otra versión de MySQL Server (via TCP/IP, o a través del uso de sockets Unix o Windows named pipes). Las consultas pueden enviarse y recibirse los resultados usando la API estándar MySQL .
NDB:

Significa Network Database, y se refiere al motor de almacenamiento usando para permitir MySQL Cluster. El motor NDB soporta todos los tipos de columna MySQL habituales y comandos SQL , y cumple las reglas ACID. Este motor proporciona soporte para transacciones (commits y rollbacks).
Arquitectura de compartición cero:

Arquitectura ideal para MySQL Cluster. En un entorno sin compartición, cada nodo se ejecuta en máquinas separadas. La ventaja de este entorno es que ninguna máquina puede ser un punto de fallida único o como cuello de botella del sistema.
Almacenamiento en memoria:

Todos los datos almacenados en cada nodo de datos se mantiene en memoria en la máquina del nodo. Para cada nodo de datos en el cluster, debe tener disponible una cantidad de RAM igual al tamaño de la base de datos multiplicado por el número de réplicas, dividido por el número de nodos de datos. Por lo tanto, si la base de datos ocupa 1 GB de memoria, y quiere tener 4 réplicas en el cluster, necesita para cada nodo un mínimo de 500 . Tenga en cuenta que esto es además de cualquier requerimiento para el sistema operativo u otra aplicación que puede ejecutarse en el equipo.
Tabla:

Como es normal en el contexto de bases de datos relacionales, el término “tabla” denota un conjunto ordenado de requistros de idéntica estructura. En MySQL Cluster, una tabla de base de datos se almacena en un nodo de datos como un conjunto de fragmentos, cada uno de ellos se replica en nodos de datos adicionales. El conjunto de nodos de datos replicando el mismo fragmento o conjunto de fragmentos se conoce como grupo de nodos.
Programas del Cluster:

Son programas de línea de comandos usados para ejecutar, configurar y administrar MySQL Cluster. Incluyen demonios:
- ndbd:
  
  Demonio de nodo de datos (ejecuta un proceso de nodo de datos)
- ndb_mgmd:
  
  Demonio de servidor de administración (ejecuta un proceso de servidor de administración)
y programas cliente:
- ndb_mgm:
  
  El cliente de administración (proporciona una interfaz para ejectuar comandos de administración)
- ndb_waiter:
  
  Usado para verificar el estado de todos los nodos del cluster
- ndb_restore:
  
  Restaura datos del cluster de una copia de seguridad
Para más información de estos programas, consulte Sección 16.5, “Gestión de procesos en MySQL Cluster”.
Log de eventos:

MySQL Cluster loguea eventos por categoría (arranque, parada, errores,checkpoints, y así), prioridad, y severidad. Un listado completo de todos los eventos reportables pueden encontrarse en Sección 16.6.2, “Informes de eventos generados por MySQL Cluster”. Los logs de eventos son de dos tipos:
- Log de Cluster:
  
  Mantiene un registro de todos los eventos reportables deseados para el cluster entero.
- Log de Node:
  
  Un log separado que se mantiene para cada nodo individual.
Bajo circunstancias normales, es necesario y suficiente mantener y examinar sólo el log del cluster. Los logs de nodo tienen que ser consultados sólo para desarrollo de aplicaciones y depuración.

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

Nodo	Dirección IP
Nodo de administración (MGM)	192.168.0.10
Nodo MySQL server (SQL)	192.168.0.20
Nodo de datos (NDBD) "A"	192.168.0.30
Nodo de datos (NDBD) "B"	192.168.0.40