¿Qué es un cluster?

En sentido genérico, un cluster es un conjunto de máquinas funcionando como unidad

y trabajando juntas para tratar una única tarea, ahora bien, un MySQL Cluster se
refiere a un grupo de máquinas trabajando juntas usando el motor de almacenamiento
NDB (“Network Database”) de MySQL para implementar almacenamiento de datos,
recuperación y administración distribuida entre varias máquinas, lo que nos permite
soportar una base de datos MySQL distribuída en una arquitectura de compartición nula
usando almacenamiento en memoria.

Como mínimo se necesitan tres máquinas para la ejecución de un cluster, 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 continuo en caso que un nodo de datos falle.

¿Qué hacen las distintas máquinas en un cluster?

Un Cluster MySQL está compuesto por los siguientes componentes:
a. nodo de administración (ndb_mgmd) : 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.
b. nodo de datos(ndbd): Almacena y replica datos. La funcionalidad de los nodos
de datos la trata una instancia del proceso NDB ndbd. Estas serán las máquinas
más potentes del cluster, almacenarán los índices en memoria y los datos en
memoria o disco. Todos los Data Nodes deben tener el mismo hardware para
evitar crear cuellos de botella.
c. API nodes (mysqld) Nodo a traves del cual accedemos a los datos.
Se trata de un mysqld con el conector para los ndb.

De esta forma podremos escribir o leer datos de nuestra BBDD como hemos
hecho hasta ahora, mediante comandos SQL.

Se recomienda que cada componente esté instalado en una máquina física

distinta.
Aunque el nodo de administracion y el API nodes pueden ir en la misma maquina
 Características:

Para comunicación entre nodos, el clúster 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 clúster entero. Recomendamos que
MySQL Clúster se ejecute en su subred que no está compartida con máquinas no-
clúster por las siguientes razones:

a) Seguridad: La comunicación entre nodos del clúster no está cifrada. La única forma de
proteger transmisiones dentro de un MySQL Clúster es ejecutar su clúster en una red
protegida.

b) Eficiencia: Inicializar un MySQL Clúster en una red privada o protegida permite

que el clúster haga uso exclusivo del ancho de banda entre máquinas del clúster.
Funcionamiento interno

Internamente, el funcionamiento del cluster se basa en dos conceptos básicos.

Replicación interna síncrona y auto particionado de datos. La primera nos ofrece la
redundancia y el segundo nos da la escalabilidad. Importante diferenciarlo de la replicación
típica de MySQL (asíncrona). En este caso, hasta que los datos no han sido replicados en
los nodos seleccionados no se devuelve el control al usuario, obteniendo de esta forma la
consistencia que no tenemos en la replicación asíncrona.

El particionado (PARTITION BY KEY) es también totalmente automático. El cluster se

encarga de dividir las tablas en distintas particiones y dividir los datos entre los
distintos Data Nodes. Aunque es posible que definamos nuestro propio particionado, no se
recomienda. Añades complejidad y posiblemente el rendimiento no sea el esperado.

Replicas

A la hora de configurar nuestro cluster, una de los valores más importantes a tener en
cuenta es decidir el número de replicas que tendremos de nuestros datos. No podemos
decidir cualquier número, si no que tendremos que seguir unas sencillas reglas. Pongamos
por ejemplo que tenemos 4 Data Nodes. En este caso podremos tener 1, 2 y 4 replicas.
Esto es, el número de nodos debe poder ser divisible por el numero de replicas. Aún
así, no se debería tener una única replica, ya que eso no nos da ningún tipo de alta
disponibilidad ya que al caerse un solo nodo perderíamos el acceso a los datos.

Node Groups

MySQL Cluster agrupa automáticamente los Data Nodes en grupos. Esto no está
bajo nuestro control ni podemos decidir que nodo está en que grupo, será trabajo del
cluster hacer estas agrupaciones. Siguiendo el ejemplo anterior, si tenemos 4 Data
Nodes y 2 réplicas, MySQL Cluster nos generará dos Node Groups (4/2=2). Además
hay que tener en cuenta que el número de particiones que se harán de nuestros datos
siempre será igual al número de Data Nodes.

Por lo tanto, imaginemos que tenemos el N1 y N2 en el grupo 1 (G1) y N3 y N4 en el grupo

2 (G2). A la hora de particionar y repartir los datos es necesario pensar en la alta
disponibilidad, por lo que el particionado se hará de la siguiente forma:
G1
N1 = P1 y P2'
N2 = P2 y P1'

G2
N3 = P3 y P4'
N4 = P4 y P3'
Siendo PX el número de la partición y PX' una copia de la partición de Backup.
Gráficamente

Sabiendo esto, podemos imaginar cuando dispondremos de alta disponibilidad. Mientras al

menos uno de los nodos de un grupo esté levantado, el cluster estará online. Por ejemplo
se podrían caer N1 y N4 o N3 y N2 y todo seguiría funcionando. Pero una caída de N1 y
N2 dejaría el cluster completamente caído.

A mayor número de replicas menos posibilidades de fallo, más escalable y más

throughput (volumen de información que fluye a través de un sistema).
Topología:

Hardware:

 3 COMPUTADORAS CON WINDOWS 7

 MYSQL CLÚSTER EN C/U DE PC
 SWITCH
 CABLES DE RED

Procedimiento:

Descargamos el cluster mysql de la siguiente dirección: http://dev.mysql.com/downloads/cluster/

Definimos nuestro sistema operativo y descargamos: