Showing entries 1 to 5
Displaying posts with tag: cluster (reset)
En MySQL Cluster existen diferentes formas de hacer backup y debido a...

En MySQL Cluster existen diferentes formas de hacer backup y debido a su arquitectura distribuida hay unas más recomendables que otras. Aquí vamos a ver la nativa, usando el cliente nbd_mgm. Desde esta herramienta de control podremos lanzar ordenes de backup que ejecutará cada nodo de almacenamiento, sacando un snapshot consistente de los datos y sin necesidad de parar el sistema.

Un backup en MySQL Cluster consiste en tres ficheros:

  • Metadatos

BACKUP-backup_id.node_id.ctl

Es un fichero donde se guardan las definiciones de las tablas.

  • Datos de las tablas

BACKUP-backup_id-0.node_id.data

Cada nodo guardará en este fichero los fragmentos de las tablas que gestiona.

  • Log de transacciones

BACKUP-backup_id.node_id.log

Es el log de las transacciones con commit de las que se harán backup.

[Lea más]
A partir de la versión 7.0 y 7.1 se han añadido nuevas...

A partir de la versión 7.0 y 7.1 se han añadido nuevas funcionalidades a MySQL Cluster que aumentan tanto la escalabilidad como el rendimiento de la base de datos. La nueva mejora que hoy voy a tratar aquí es la posibilidad de añadir nuevos nodos de almacenamiento a nuestro cluster en caliente sin necesidad de hacer una parada de mantenimiento.

A la hora de escalar nuestro cluster hay que tener en cuenta siempre el número de réplicas (NoOfReplicas) y el número de nodos que queremos. Debemos recordar que dicho número debe ser divisible y al mismo tiempo que tanto uno como otro tienen un límite. En el ejemplo que voy a mostrar tendremos la base de datos con dos réplicas y dos nodos y lo pasaremos a 2 réplicas y 4 nodos. De esta forma, pasaremos de tener un único Node Group (2/2=1) a tener dos Node Groups (4/2=2).

El primer paso es configurar los Management Node. Para ello añadimos los dos nuevos ndbd a los ficheros …

[Lea más]
Una vez que conocemos la teoría, vamos a poner en marcha nuestro...

Una vez que conocemos la teoría, vamos a poner en marcha nuestro primer Cluster. Estará compuesto únicamente por 3 ordenadores.

Nodo 1 (192.168.1.106):

  • ndb_mgmd
  • mysqld

Nodo 2 (192.168.1.104):

  • ndbd

Nodo 3 (192.168.1.105):

  • ndbd

Esto es, el nodo 1 será un Management Node + API Node y los dos restantes Data Nodes.

Lo primero de todo es descargarnos MySQL Cluster de http://dev.mysql.com/downloads/cluster/

La instalación es tan sencilla como descomprimir el fichero y copiar a nuestro PATH los ejecutables que necesitemos. Por lo tanto, llevaremos a /usr/bin/ los ejecutables ndbd, ndb_mgmd, ndb_mgm, mysqld, mysqld_safe.

Para tener un poco ordenadas las cosas, creamos la carpeta /etc/mysql-cluster/ donde alojaremos el fichero de …

[Lea más]
Introducción a MySQL Cluster

MySQL Cluster es una base de datos que como su nombre indica funciona en un Cluster de servidores. Mucha gente confunde terminos y define un conjunto de servidores con replicación como un MySQL Cluster, pero hay que tener en cuenta que son dos conceptos totalmente distintos. MySQL Cluster nos ofrece:

  • Alta disponibilidad
  • Escalabilidad
  • Failover automático
  • Redundancia
  • Alto throughput

La versión actual es la 7.1 y puede descargarse de http://www.mysql.com/products/database/cluster/

Componentes

Un Cluster MySQL está compuesto por los siguientes componentes:

Manager (ndb_mgmd): es un servicio encargado de poner en marcha el cluster, conectar nuevos servidores y ejecutar distintos comandos de administración mediante el CLI ndb_mgm. Una vez que …

[Lea más]
Alta disponibilidad en replicación con Mysql-MMM

Montar un sistema de replicación es sencillo y rápido. Nos ofrece muchas ventajas, siempre y cuando funcione correctamente y no fallen los equipos. Ahora imagina con las siguientes características:

  • Dos equipos en maestro-maestro.
  • 50 equipos esclavos, 25 colgando del maestro 1 y otros 25 del maestro 2.

Ahora imagina que el maestro 1 se cae. Bien, recuerda que todo esto está en tu imaginación, no te intentes suicidar, aunque he de admitir que sería la solución mas razonable. Con la caida de ese Master, 25 equipos esclavos se han quedado desincronizados. Tenemos usuarios que ni pueden escribir y lo que leen está posiblemente anticuado. Cuando pones de nuevo el servidor en marcha compruebas que no se replican correctamente ya que alguna transacción quedó a medías. Tienes 26 ordenadores desincronizados y tienes que entrar uno a uno parando el proceso Slave, ejecutando el change_master, arranco de …

[Lea más]
Showing entries 1 to 5